Conditional Interpretation of VHDL

For verilog, there is `ifdef, similar to the C #ifdef.

It seems that VHDL has if/generate, but I haven't tried it.

Otherwise, most synthesis tools are good at removing unused logic. If you code such that the unneeded signals aren't used, the logic to generate them won't be, either.

But it looks to me like if/generate should do what you want.

-- glen

I'm not sure if if/generate will help if what you want is to define a different set of module ports. `ifdef is pre-processed, so you can slap it anywhere in the code to conditionally include or leave out items.

Speaking VERY generally here, but I think it's appropriate...

The usual way to solve this sort of thing is to group the requisite shared logic in shared files. Then have two unique top levels which just feed the approprate signals down to the shared modules.

Pretty straightforward really; shared code lives in shared files. Unique code lives in unique files. If you find yourself cut/pasting code too much, you need to rethink the code organization.

Also, do rely on synthesis optimizations, as Glen indicated. These tools are VERY mature, and very good at their job. If your shared code includes some redundant (or unused) information in a certain solution, that's ok - leave it dangling unused. The optimizer will remove the unusued logic just fine. Similarly for inputs to shared modules - tied constants at inputs are optimized just as easily (through sequential stages too).

Regards,

Mark

(snip on optional logic for two choices)

Yes, it probably doesn't do that.

I was thinking of the case where the ports have different signals for the two cases, or aren't used for one.

That sounds about right to me, though it depends on the actual goal.

With big FPGAs, it is almost as easy to generate logic and use only the parts you need.

I remember all those times where a tiny logic mistake causes the tools to remove everything. It takes some tracing back to see why it did that.

-- glen

I'm not sure you will find much difference keeping two projects up to date and keeping one project with two projects nested within "if" statements. I've tried this before and found it to be a royal PITA. The size of each file grows and the conditionals make the code much harder to read.

What I ended up with was to encapsulate the two varieties in two separate files (rather than letting the differences be spread across the project) and built two separate projects. They were still 90+% the same so a lot of testing could be reused.

I think I need to do that any way, but I am finding it mildly challenging. I probably need to re-organize the code...

OK I am sure I can do that but I.

Dave

Except when it doesn't.

For instance, I have a toplevel model that defines some ports that are driven by transceivers. The pins are configured with appropriate I/O standards etc in the project configuration.

Let's say I change my PCIe port from 4x to 1x, which is a simple dropdown on the PCIe core. If I have the ports on my toplevel module, but don't connect them to anything, I get an error. If I remove the ports from my toplevel module, but leave the transceiver settings alone, it compiles.

The result is I have to do:

module toplevel ( output PCIE_TX0_p, input PCIE_RX0_p, `ifdef PCIE_LANES_2X output PCIE_TX1_p, input PCIE_RX1_p, `ifdef PCIE_LANES_4X output PCIE_TX2_p, input PCIE_RX2_p, ... `endif `endif )

This is an unusual corner case, but there's an unusual case around every corner.

Theo

(snip)

This might depend on VHDL or veriog, but sometimes I assign Z to I/O ports, which will make the tools happy, and I can still use them as input ports. It might be that you can still also assign output values.

Or you could use `ifdef or IF/GENERATE to assign them either the real value or a constant value. I usually assign constants instead of remove ports. (It makes it easier to add back later.)

The one that keeps bothering me, is that you can't have lines in the UCF file for ports you aren't using.

It would be really nice to include the whole UCF, and have it ignore the ports that your design didn't need (yet).

-- glen

A standard way to do this without `ifdef is to make the ports vectors and use a parameter to define the port width. At least that's how the xilinx cores do it, and it works for either VHDL or Verilog. It's a bit clunky to refer to a lane as TXn[3] / TXp[3] (one bit slice of each of two "vectors" to make a differential pair) but it works.

You can certainly leave constraints for unused ports in Xilinx tools. There's a couple of command line options, -aul and -aut IIRC to allow unmatched LOC constraints and unmatched timing constraints. In some versions of ISE, you can place all constraints for a port, LOC, IO Standard, Slew, Pullup, etc. on one line using | between constraints and the -aul will ignore the full line. In other versions the -aul just ignores some of the constraints and errors out on others. Oh, well...

(snip, I wrote)

So far, I use the GUI, but sometime should switch to the command line version. Maybe the GUI allows it, too, but I didn't see where.

-- glen

That works if I'm changing the width of a port, but what if I'm not using PCIe at all today? I don't believe you can do:

`parameter PCIE_WIDTH -1

output [`PCIE_WIDTH:0] PCIE_TX_p;

and hope that it'll delete PCIE_TX_p completely.

Most of the time this works for Altera too, it's the case of transceivers where it doesn't. I have no idea why, it's arguably a bug in the tools.

The tools don't like partitions or LogicLock regions which aren't associated with logic, but that's more likely to be a bug that you want to be alerted of. It's a pain when the list of modules in your design is configurable, though.

Theo

In the GUI you go to translate properties --> "Other NGDBuild command line options" and there you can add any options you want. However more recent versions of the GUI have -aul and -aut as check boxes as well.

I never got why the DEFAULT behaviour is to quit with an error when there's LOC constraints for non-existant ports, but only issue a warning (which easily gets lost amongst thousands others in the logs) if an existing port is NOT location constrained. The tool then places the IO randomly, and this is most certainly not the desired behaviour, since you could potentially damage hardware when you're driving an IO that connects to something that should not be driven. Unlikely, but possible.

The only exception I can think of is in the hardware concept phase, when you want to let the tools chose a valid pin out for you that you can then copy to your schematic. But that is a rare case that IMHO would justify an extra mouse click or an added command line switch.

This DEFAULT behaviour is stupid IMHO. Of course you can change it with obscure command-line switches or a setting hidden away in some "Advanced" tab, but someone at Xilinx must have deliberately chosen to make this the default behaviour for whatever reason, and I don't get it. I think this is one of these things that got introduced in a very early software release, and even though it doesn't make any sense at all, it was never fixed because people would get confused if the default behaviour changed.

I think Vivado now issues a "Critical Warning" by default for unconstrained ports. Sounds better, but when you think about it, it doesn't help a lot, since critical warnings also do not stop the flow (unless you promote that warning to an error). Unless you use the GUI, those critical warnings can also easily get lost in the log files if you don't specifically look for them, especially when you use a purely command-line driven flow like me.

Not to mention that I don't understand what the hell a "Critical Warning" is supposed to be. Either it's a warning, or it's critical, and then it'd better be an error. What sense does it make to introduce another severity level in between "warning" and "error"? I personally have not seen a "critical warning" that did not cause me to re-run the entire flow, and then it would have been better to stop the flow right the moment the critical warning occured as not to waste my time. That's why I've promoted all critical warning to errors, which fortunately is easy enough in Vivdao via Tcl.

, Sean

(snip on ignoring UCF entries for pins that don't exist.)

OK, I did that.

Thanks!

This is especially useful for starter boards which have a lot of pins that you aren't using, but also for general purpose boards, again with extra pins that you might not be using.

-- glen