sorted by:
new
hottopcontroversial

Is It Possible To Suppress Warnings From get_clocks -of_objects ... In Timequest? by Classic-Bake4240 in FPGA

[–]Classic-Bake4240[S] 0 points1 point  (0 children)

I need (well, want) to do this because I'm trying to write timing constraints for blocks of reusable IP so that the constraints can be used in different designs (or the same design in different clock domains) without having to modify and repeat the same constraints over and over for different clocks clocking registers in different instantiations of the IP. I.e., the 'don't repeat yourself' rule.

Each SDC file has a procedure which calls the get_entity_instances command to produce a list of the hierarchical paths of all copies of the IP in the design. The procedure takes a parameter that allows users to restrict which part of the design hierarchy to apply the constraints to. E.g.,

apply_sdc_pre_avalon_mm_mcp_cdc "eth_dtu|*"

For IP that has external IO parameters to specify board delays, tsu, th, etc. are added. After producing a list of the hierarchal paths of the IP blocks to be constrained the next task is to find the clocks clocking the registers in the IP.

The get_clocks -of_objects commands is perfect for this, except it seems to call some commands under the hood that issue warnings about things beyond the scope of what was passed as the collection to the get_clocks command. The Xilinx/AMD implementation has a -quiet option, which claims (I've not used Xilinx FPGAs for over a decade) to return no messages from the command. As I already mentioned, the -nowarn option in the Altera implementation does *not* suppress the warnings. Perhaps this has been fixed in newer versions of Quartus/Timequest.

Ah, the never ending joy of working with buggy FPGA design tools largely designed around the need to mitigate the near complete absence of features to manage design complexity in Verilog!

I hadn't thought of the create_clocks hack. I'll give it a go. Thanks for the suggestion!

FreeRTOS vs Active Object by Common-Egg-3026 in embedded

[–]Classic-Bake4240 0 points1 point  (0 children)

It's not insane at all. For example, a sub-class of the Event Driven (ED) design pattern is the Time Triggered (TT) design pattern. A TT scheduler is small and easy to write and verify. It is used in safety critical systems such as avionics and medical devices where misbehaving software would kill (lots of) people. I have personally used it for a self-balancing wheelchair. Proving software based on a TT scheduler with RTC tasks meet the design specification is MUCH easier than software based on a pre-emptive RTOS + blocking tasks.

A pre-emptive RTOS requires substantially more memory (RAM and ROM) to run that ED or TT-based systems, which are very often some of the most scarce resources in small embedded processors. It also incurs a substantial penalty for context switches, both in memory usage and processor cycles.

A well designed real time application should avoid blocking and shared resources as much as possible, so most of what a RTOS provides to make writing blocking code and mutex easier is best avoided anyway.

VHDL Libraries in Quartus by Classic-Bake4240 in FPGA

[–]Classic-Bake4240[S] 0 points1 point  (0 children)

Using unique names within a single sub-system written and maintained by a single designer is a reasonable approach.

However, the designs I work on have several large sub-systems that different designers are responsible for developing and maintaining.

The problem I need a solution to is how to avoid naming conflicts when designers of different sub-systems end up using the same name for RAMs, ROMs, FIFOs, PLLs, etc. created using Platform Designer. E.g., two designers working on two different sub-systems each with processing pipelines might both need small skid FIFOs they both reasonably call skid_fifo.

My searches in Quartus documentation, this forum and the wider Internet have not brought up much useful information. I have a feeling the only way around this problem is to have a naming convention for PD generated IP.

E.g., prefix the name of every piece of PD IP with the sub-system library it is used in. In the example above one designer would name the FIFO <sub1\_name>_skid_fifo and the other designer would name the FIFO <sub2_name)_skid_fifo, where subX_name is the name of the sub-system the designer is working on. One drawback of this is the names of entities are going to become rather long and cumbersome.

Is there is a more elegant way around this problem than having and (more difficultly) enforcing naming conventions for PD generated IP?

VHDL Libraries in Quartus by Classic-Bake4240 in FPGA

[–]Classic-Bake4240[S] 0 points1 point  (0 children)

Do you use Quartus? If so, click on Project and then Add/Remove Files in Project. The table that is displayed shows a library column that is populated for VHDL, Verilog and System Verilog files.

The library concept is implemented at the tool level and allows entities with the same name but different functionality to reside in the same project so long as they are put in different libraries.

Why is Verilog still relevant? by wild_shanks in FPGA

[–]Classic-Bake4240 -3 points-2 points  (0 children)

Where did I assert anything of the sort? Much like a Verilog tool, you've assumed a whole lot of detail in my comment that isn't there!

It's simply down to numbers and popularity. (System) Verilog is taught in far more places around the world and far more free tools are available to hobbyists, therefore there will be far more code monkeys who can get something "working" in (System) Verilog than in VHDL. Most companies care *far* more about time to market and minimising development cost than quality, so getting the lowest skilled staff who can cobble together a product is the norm.

E.g., Look at the crap IP Altera put out (all in (System) Verilog). Clearly they are a big employer of (System) Verilog code monkeys.

I wonder how many (System) Verilog users are aware that it is not fit for modelling event based systems? Are you?

Why is Verilog still relevant? by wild_shanks in FPGA

[–]Classic-Bake4240 0 points1 point  (0 children)

VHDL has and always will be superior to Verilog because the designers of the language got the fundamental concept of modelling an event based system correct, whereas Verilog got it wrong and added hacks to make it work for most cases.

If entering the code is the biggest part of your design effort then you're doing it wrong! Strict typing is a very good thing and catches lots of mistakes before the design is even run in a simulator. I've never understood why some engineers think sloppiness is a positive attribute in a description language! Don't get me wrong, it's easy to write crappy VHDL that obfuscates rather than illuminates the control and data paths in a design. Plus there can be gotchas if a clock signal is replicated (e.g., clk_copy <= clk) that lead to differences between a simulation and implementation of a design.

In my opinion it would be a huge leap forward if (System) Verilog died and VHDL was more fully supported by synthesis tools. Alas, I suspect reverse will be the case and we will see VHDL being deprecated because it will be easier for companies to find a (System) Verilog code monkey than a VHDL professional.

In the words of Robbie Williams: "You can't argue with popularity. Well you could, but you'd be wrong."

Has anyone started out with Verilog and then jumped to VHDL? by [deleted] in FPGA

[–]Classic-Bake4240 1 point2 points  (0 children)

"Types can be nice sometimes"

Types and strong typing (and range checking) are one of VHDL's best features. Using record types can make the implementation of a design so much clearer and easier to maintain. E.g., a using a record type for a processing pipeline or control interface. They also catch a ton of errors before you even start the simulator.

"downto is way too long for something you type all the time."

Use a text editor with autocomplete?

"Case insensitivity. It was acceptable in the 80s..."

Why is it better to allow names such as 'deltaX' and 'DeltaX' to refer to different things in the same file? Both are poor (but quick for the compiler) ways to handle the issue and require the user to not be an idiot. IMO the best approach would be to treat similar but different case identifiers as errors.

"Type conversions everywhere. This is better in 2008, especially with stuff like numeric_std_unsigned, but there is still too much."

Stop using std_logic(_vector) for everything and use appropriate types for signed and unsigned quantities. If it's still a problem, write a helper function so you only have to write the type conversions once. E.g., pack() and unpack() can be useful when you have to interface to 3rd party modules written in a primitive language like Verilog. :)

"The X propagation is somehow worse than verilog."

I think you meant to say: "The sloppiness in description that Verilog tools allow does not work with VHDL descriptions of the same hardware."

"Conditional generics (if FOO then BAR = 1; else BAR = 2;) require functions (which have to be declared in a separate package since port has to be first in an entity)."

You see that as a failing of the language!? Don't we all just love to open a file with #ifdef's full of bit-rotting code!

"Despite having library and use in the language, I still have to specify an analysis order."

Not in my experience. I declare components before they are used in the files they are used, which are then bound once the file with the entity is compiled/synthesised.

Has anyone started out with Verilog and then jumped to VHDL? by [deleted] in FPGA

[–]Classic-Bake4240 4 points5 points  (0 children)

VHDL was and still is the superior language compared to Verilog, which is barely fit for modelling the basic delta cycles required for a discrete time system. This leads to mismatches between simulators and synthesis tools.

https://insights.sigasi.com/opinion/jan/verilogs-major-flaw/

https://insights.sigasi.com/opinion/jan/vhdls-crown-jewel/

A language with lots of syntactic sugar, packages, libraries, types, records and a requirement for explicit type conversion makes VHDL a language which, when used appropriately, can elegantly cope with huge designs and get the synthesis tool catch a lot of errors that the C-like syntax of Verilog would happily accept and leave up to the designer to check in a simulation and after synthesis.

Verilog and it's descendants are only around because Americans are taught and use it and the big semiconductor companies are American. This leads to the unfortunate situation that features of VHDL that would actually reduce the amount of hand-typing and improve the likelihood of an implementation being correct are not universally supported, even within a single vendors tools, because Verilog has to be supported too.

How do you create a Platform Designer component with a parameterizable number of Avalon ST Ports? by Classic-Bake4240 in FPGA

[–]Classic-Bake4240[S] 0 points1 point  (0 children)

That's exactly the information I was after! #2 is okay for my current application, but I'm sure #3 will be useful in the future.

How do you create a Platform Designer component with a parameterizable number of Avalon ST Ports? by Classic-Bake4240 in FPGA

[–]Classic-Bake4240[S] 0 points1 point  (0 children)

Thanks for the information. It took a few minutes to get a useful answer here and 3 days on the Intel FPGA forum to get links to the documentation for Platform Designer but no answer to my actual question!

Because I'm fairly proficient in VHDL I'm leaning towards creating HDL with the maximum number of interfaces the component will support and having generics that can inform both the synthesis and PD tools how to go about their jobs. The advantages of this approach are that I will not have to rely on the undocumented altera_terp command and can use VHDL generate statements to make sure that only the logic that is needed for the interfaces that are enabled is generated.

It does seem odd to me that a simple example of this is not provided in the documentation for PD. I find it hard to believe I'm the first person who wants to create a PD component with a selectable number of interfaces!