Verilog `ifdef equivalent in VHDL

[Altera_Forum]

Hi 

 I've just learned that in Verilog you can use an `ifdef statement that makes Quartus ignore the following code (until the next`endif) you can define a macro in the qsf file (or through the GUI) to decide which parts of code to ignore.  is there an equivalent in VHDL? the closest tool I'm aware of is the "if generate" statement but it is a weaker tool since: 1) you can use it only in the architecture body 2) the synthesizer first makes sure that the code inside the statement is compilable. this is a problem if you wish to omit other sections in the code.  can anyone can enlighten me? I'm used to VHDL, but I this single feature will make me switch sides.:)

[Altera_Forum]

there is the option for: 

 --synthesis translate_off  any code here is ignored for synthesis, but will still run in a simulator. --synthesis translate_on  While this is greate for simulation only processes and the like, it doesnt quite do what you want. The only way to do what you want is with generates.

[Altera_Forum]

Hi Tricky 

 What I'm missing in the "--synthesis translate_off " statement is that it is not conditional.  It's great if you have a bit of code that you wish to omit under some condition (synthesis verses simulation), but what happens if you want to replace a part of your design with something else?  For example lets say I wish to instantiate a DFF instead of SRFF, In that case I will have to define the pins for the SRFF even when I'm using the generate statement for instantiating only the DFF. I can use the same pin names for both components, but for large designs it's confusing, and then you have width mismatch etc.

[Altera_Forum]

the only way you could do it is with generates. 

You could of course hide the generates under another level of heirarchy.  Otherwise there is no way to do it, because there is no pre-compiler in VHDL.

[Altera_Forum]

--- Quote Start ---   What I'm missing in the "--synthesis translate_off " statement is that it is not conditional.  It's great if you have a bit of code that you wish to omit under some condition (synthesis verses simulation), but what happens if you want to replace a part of your design with something else?  For example lets say I wish to instantiate a DFF instead of SRFF, In that case I will have to define the pins for the SRFF even when I'm using the generate statement for instantiating only the DFF. I can use the same pin names for both components, but for large designs it's confusing, and then you have width mismatch etc.  --- Quote End ---  There's a few methods that I've used;  1) For simulation vs synthesis   -- altera translate_off Modelsim only ports or code goes here -- altera translate_on -- synthesis read_comments_as_HDL on -- Quartus-only code goes here (inside a comment block) -- synthesis read_comments_as_HDL off 2) For variations in hardware functionality I use generics and generate blocks, eg., to select between single-clock or dual-clock FIFOs in a bridge component.  3) For abstraction of components that differ between families, eg. RAM blocks (altsyncram vs lpm_ram_dq), use a component definition in the code, and then a VHDL configuration to map the component to the specific memory type.  Cheers, Dave

[Altera_Forum]

Hi Dave 

All off these methods can be a little awkward when all you want is to change a couple of pins names in an entity with 30 - 40 pins.  anyway I think I found my answer (http://www.vhdl.org/siwg/old-hm/0135.html)and it is a NO. now I have to decide if I rather use an external preprocessor or start to learn Verilog.  I have to admit I was always convinced that anything you can do with VHDL you can do with Verilog and vica versa.  I am a little bit surprised to learn that it isn't so.

[Altera_Forum]

I dont understand why you would be wanting to change some pin names. These are usually fixed, with sizes configurable via generics.

[Altera_Forum]

--- Quote Start ---  I dont understand why you would be wanting to change some pin names. These are usually fixed, with sizes configurable via generics.  --- Quote End ---    Let's say I my top component has 200 pins names.  Now I have a new board revision that one of the ICs is a little different,  for example a serial instead of a parallel interface.  Without# ifdef I will have to maintain 2 files for the top component because the number of pins is changed, I also try to keep my logic names identical to the names in the schematic, so the names will probably be spi_en Vs. bus_cmd etc... I usually encapsulate this interface inside a component that might have other logic besides the outside world pins, such as FIFOs, CPU interface, connection with other logic blocks... without# ifdef I will need to duplicate this file also... Any change I do to other parts of the code will have to be copy pasted to other copies of the files. I can see the mess it will cause :(  An# ifdef makes my life quite easy :). but I'm sticking with VHDL. I'm now trying to write some tcl script to do it for me. I hope to upload it when I'm done.

[Altera_Forum]

If I remember right, the technique has been mentioned in several threads before. The most simple option is to keep all optional pins in the port definition of a common top entity file.  

 Use version dependent generate and if statements to access one or the other pin set. I'm using this method in several projects and don't see a problem with it.  I agree, that it would be convenient to have a Verilog or C alike preprocessor with VHDL. But I didn't experience a situation where the respective problem couldn't be handled with VHDL means somwhow.

[Altera_Forum]

Hi FvM 

 Of course it can be done your way, but I don't like: 1) having lots of unused virtual pins on my top level and in every partition, the added LE's might be negligible, but as an engineer I simply don't like it.   2) Personally I find this code more readable:    --- Quote Start ---   comp:interface port map( l o n g l i s t# ifdef dff d end if# ifdef srff s r# endif   --- Quote End ---  rather then   --- Quote Start ---   dff: if DFF gnerate comp:interface port map( l o n g l i s t  d end generate  srff: if SRFF gnerate comp:interface  port map(  l  o  n  g  l  i  s  t    s r  end generate   --- Quote End ---  and if you get a 3rd option it's get worse...

[Altera_Forum]

I agree about readability, although VHDL comments can clarify which pins are actually used. 

 Virtual pins actually consume an unconnected LE in gate level netlist, don't know why.  In my opinion, all these points aren't a sufficient reason to change the design top to Verilog.

[Altera_Forum]

--- Quote Start ---  If I remember right, the technique has been mentioned in several threads before. The most simple option is to keep all optional pins in the port definition of a common top entity file.   Use version dependent generate and if statements to access one or the other pin set. I'm using this method in several projects and don't see a problem with it.  I agree, that it would be convenient to have a Verilog or C alike preprocessor with VHDL. But I didn't experience a situation where the respective problem couldn't be handled with VHDL means somwhow.  --- Quote End ---    How do you place multiple ports onto the same pin in PinPlanner ... you can't I'd think?

[Altera_Forum]

I'm assuming, that each of the different FPGAs has it's own Quartus revision and respective pin assignments.

[Altera_Forum]

--- Quote Start ---   Virtual pins actually consume an unconnected LE in gate level netlist, don't know why.  --- Quote End ---   I assume it has something to do with partitions. If you'll use your project as a partition in another project, that now virtual pin might become a constant driver.   --- Quote Start ---   In my opinion, all these points aren't a sufficient reason to change the design top to Verilog.  --- Quote End ---   I tend to agree, though I've never worked with Verilog, I'm quite happy with the VHDL capabilities. that's why I'm writing a small preprocessor in tcl to add to the pre flow script.    --- Quote Start ---  I'm assuming, that each of the different FPGAs has it's own Quartus revision and respective pin assignments.  --- Quote End ---   correct. I always assign pins in the qsf file, not in the VHDL code. I find it more readable, and reusable.