Vhdl 'device_family'

[Altera_Forum]

Is there an equivalent of the AHDL predefined Altera parameter DEVICE_FAMILY in VHDL? I have a single module to instantiate a Fifo (as I don't like to generate fixed components using the MegaWizard). Now I'm trying to impose the type of block-ram to be used, but e.g. Stratix II has M512, M4k and M-Ram, where e.g Cyclone IV only has M9K. I want to specify the RAM_BLOCK_TYPE using the 'lpm_hint' generic but I then I need to identify the device family at hand.

[Altera_Forum]

Hi Josy, 

   --- Quote Start ---   first thing I did this morning was to set up the projects and compile/test all three. Made a small change to example three and 'played' it. It works great and I will certainly use this approach in my project.   --- Quote End ---  Ah, so you do see the error of your ways ... :)    --- Quote Start ---   The only thing to change is that we have different sensors on one side and different interfaces at the other side. In the past we just kept the list of general IO pins, like s[7..0], id[11..0], ld[27..0], and declared most of them all bidirectional and the connected them to their respective pins from the sub-module. This off course provokes a considerable amount of warnings.    --- Quote End ---  Really, what warnings?  If you have an I/O that you only use an input, just drive it with 'Z', and you won't get warnings about there being no drivers.    --- Quote Start ---   I can add different sections in the share\scripts\constraint.tcl file, set a variable before sourcing the constraint.tcl script and ready we are!   --- Quote End ---  Another way to work around things like this would be to figure out how to ask Quartus what the pin names in a design are. I think you can do this by splitting the synthesis phases, i.e., (1) elaborate the VHDL, (2) ask for a list of pin names, (3) in the constraints file, generate the pin assignments based on the actual pins used in the design, (4) set unused pins to inputs tri-stated or with pull-ups.    --- Quote Start ---   May I suggest you create a page on the Altera Wiki, what you made up here surpasses the examples in the Altera documentation by far.   --- Quote End ---  The Altera wiki is by far the ugliest I have ever seen ... there is no 'table of contents', navigation is a nightmare ... but we can do that if you like.  Actually, my approach is not quite so elegant when using SOPC Builder and probably Qsys. I haven't had a chance to sit down and find a solution I am happy with. The basic problem is there is no Tcl command to call these tools, and a simple 'exec' from within Tcl does not work (since I have Cygwin tools installed too). I haven't sat down and looked at it, as its part of a bigger tools building issue I would like to solve; simulation and synthesis testing with multiple versions of Quartus and Modelsim.    --- Quote Start ---   You can avoid that 'unschöne' (unbeautiful?) 'assertion is false' in the Message window by encapsulating a report statement in a process:  process( all ) begin report "an informational message" ; end process ; It took me a while to find that out.   --- Quote End ---  Ah, I see what you mean; the VHDL does not look any different really, but the message in the Quartus window looks nicer. I don't usually put assertion messages in the synthesizeable code, but I did in this case to show that the different files were getting sythesized with different LED blink times.  BTW, process(all) is VHDL-2008, so you can add  # VHDL-2008 set_global_assignment -name VHDL_INPUT_VERSION VHDL_2008 to synth.tcl, and you're set!  Thanks for the tip!  Cheers, Dave

[Altera_Forum]

Hey Josy, 

 So which example do you like for customizing your FIFO; using generics or using configurations?  Cheers, Dave

[Altera_Forum]

Hello Dave, 

  --- Quote Start ---  Hey Josy,  So which example do you like for customizing your FIFO; using generics or using configurations?  Cheers, Dave  --- Quote End ---    I will use the generics at least for the time being, until I have some more time to study the configurations a bit deeper.    --- Quote Start ---  Really, what warnings?   If you have an I/O that you only use an input, just drive it with 'Z', and you won't get warnings about there being no drivers.  --- Quote End ---   Euh, right :oops:. But I'm still thinking about using meaningful names in stead of the place-holder names used in the schematic of the FGPA PCB.    --- Quote Start ---  BTW, process(all) is VHDL-2008, so you can add ...  --- Quote End ---   I actually saw that the projects were in VHDL93, but the compiler didn't choke on the process( all ) statement. You are right about the TOC and navigation in the Altera Wiki, but is is a place to find stuff to reflect upon. The search in the forum is even a factor 1000 worse.  Have a nice Sunday,   Josy

[Altera_Forum]

--- Quote Start ---   I will use the generics at least for the time being, until I have some more time to study the configurations a bit deeper.   --- Quote End ---  When you look at configurations, see if you can figure out a way to use a generic to switch between the two examples I gave; editing the code to switch between them seems so ugly :)     --- Quote Start ---   But I'm still thinking about using meaningful names in stead of the place-holder names used in the schematic of the FGPA PCB.   --- Quote End ---  Just write your code in another not-quite-top-level VHDL file, and then instantiate that in your actual top-level entity, i.e., write your code as blink_leds with meaningful pin names, and then just wire it up inside the top-level bemicro_sdk that has the uglier pin names.  In my projects, I organize the source as board/device/project, eg., bemicro_sdk/cyclone4/basic, bemicro_sdk/cyclone4/blink_leds, bemicro_sdk/cyclone4/avalon, etc., each top-level file is identical with regards to its pin assignments. The not-quite-top-level design is often a different source file, named the same as the project folder name.    --- Quote Start ---   I actually saw that the projects were in VHDL93, but the compiler didn't choke on the process( all ) statement.   --- Quote End ---  It (Quartus 10.1) did for me.    --- Quote Start ---   You are right about the TOC and navigation in the Altera Wiki, but is is a place to find stuff to reflect upon. The search in the forum is even a factor 1000 worse.   --- Quote End ---  Good to hear I am not alone in my impressions :)    --- Quote Start ---    Have a nice Sunday,    --- Quote End ---  You too!  Cheers, Dave

[Altera_Forum]

Hey Josy, 

 There's some Modelsim simulation script examples here that you can check out;  http://www.ovro.caltech.edu/~dwh/correlator/pdf/esc2011_fpga_dsp_code.zip (http://www.ovro.caltech.edu/%7edwh/correlator/pdf/esc2011_fpga_dsp_code.zip)  the documentation associated with that code is;  http://www.ovro.caltech.edu/~dwh/correlator/pdf/esc-100paper_hawkins.pdf (http://www.ovro.caltech.edu/%7edwh/correlator/pdf/esc-100paper_hawkins.pdf) http://www.ovro.caltech.edu/~dwh/correlator/pdf/esc-100slides_hawkins.pdf (http://www.ovro.caltech.edu/%7edwh/correlator/pdf/esc-100slides_hawkins.pdf) http://www.ovro.caltech.edu/~dwh/correlator/pdf/esc-100slides_hawkins.zip (http://www.ovro.caltech.edu/%7edwh/correlator/pdf/esc-100slides_hawkins.zip)  Cheers, Dave

[Altera_Forum]

Hi Dave, 

 the script approach to Modelsim is definitely the way to go. I must confess (although not feeling that much guilt) that I haven't used ModelSim yet. I looked into it several times, but always choked on the clumsy-messy-GUI. So I stick with QII 9.1SP2 and use the internal simulator. Now, before you start off, the work I do is rather simple. I build my design from the bottom up using building blocks. These building blocks do simple tasks and are quicker to test with the internal simulator than writing a TB and firing up Modelsim interactively. The building blocks use a standard interconnect, which is actually a subset-like of Avalon-ST. So I am assured that when I connect a string of them together, it will work. I may/will write ST-wrappers so I can later use QSys to connect them, saving some manual work.  But as Altera has dropped the internal simulator, for the newer cyclone families I will have to look in ModelSim again some time in the (near) future when I need to simulate a 'real' project. For the building blocks, I just specify the Cyclone II family and use both the Classic Timing analyser and the internal simulator. But I do use TQ for all projects and the more demanding things like SERDES interfaces, memory PHY and the like. At the time I even simulated a Stratix II GX transceiver using the internal simulator, having the project produce some output which I then copied back as input. It was a bit slow but I was able to test what I needed to.   Best regards,  Josy

[Altera_Forum]

--- Quote Start ---   the work I do is rather simple. I build my design from the bottom up using building blocks. These building blocks do simple tasks and are quicker to test with the internal simulator than writing a TB and firing up Modelsim interactively. The building blocks use a standard interconnect, which is actually a subset-like of Avalon-ST. So I am assured that when I connect a string of them together, it will work.   --- Quote End ---  Yeah, but you have to look at the simulation output to decide that it works. I prefer to have computers do dumb repetitive stuff, they're much better at paying attention.  The main thing I really like about Modelsim simulations, is that I can setup a Makefile with 'make check' target that runs all my testbenches. Each component I design has a self-checking testbench. If I'm editing my library code and I make a logical error (somehow change a bus transaction sequence/timing or something stupid), then there is a very good chance my 'make check' checks will fail, and I'll catch my error. The testbench can generate randomized transactions and generate many more tests than you would be able to manually.    --- Quote Start ---   But as Altera has dropped the internal simulator, for the newer cyclone families I will have to look in ModelSim again some time in the (near) future when I need to simulate a 'real' project.   --- Quote End ---  When you're ready, feel free to ask for a reference example. Hopefully I'll have had a chance to write up a 'Guide to scripting' and you can be the reviewer.  (It looks like I've ripped the Makefile part out of the Modelsim stuff I posted above, so don't go looking there for an example - the MAKECHECK generic in the code is used by the Makefile)  Cheers, Dave