Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.
17268 Discussions

QSYS - Errors on custom component

Altera_Forum
Honored Contributor II
4,871 Views

Hi, 

 

I try to get my custom component to work under QSYS. It worked fine under SOPC . . . 

 

I get the following error messages from the custom component wizzard: 

 

Error: System.uart_0.clock_reset: Synchronous edges DEASSERT requires associated clock 

Error: System.uart_0.avalon: Interface must have an associated reset 

Error: System.uart_0.avalon: uart_0.avalon must declare an associated reset 

Error: System.uart_0.interrupt: uart_0.interrupt must declare an associated reset 

 

I have no idea what is wrong with my vhd file. The entity is declared as follows: 

 

ENTITY uart IS generic ( GENERIC_RX_FIFO_SIZE : natural := 128; GENERIC_TX_FIFO_SIZE : natural := 128; GENERIC_INTENDED_FPGA_FAMILY : string := "Cyclone"; GENERIC_IMPLEMENT_FIFO_IN_MEMORY : string := "ON" ); port ( csi_clock_reset : IN STD_LOGIC; csi_clock_clk : IN STD_LOGIC; coe_uart_cts : IN STD_LOGIC; coe_uart_rxd : IN STD_LOGIC; avs_avalon_write : IN STD_LOGIC; avs_avalon_read : IN STD_LOGIC; avs_avalon_address : IN STD_LOGIC_VECTOR(3 downto 0); avs_avalon_writedata : IN STD_LOGIC_VECTOR(31 downto 0); coe_uart_txd : OUT STD_LOGIC; coe_uart_rts : OUT STD_LOGIC; ins_interrupt_irq : OUT STD_LOGIC; avs_avalon_readdata : OUT STD_LOGIC_VECTOR(31 downto 0) ); END uart;  

 

In the attachment, you can find the components genreated TCL file. 

 

Please advise what I have to change. I would also be happy if somebody can explain what I've done wrong here and what exactly those messages mean. 

 

Thanks, 

Maik
0 Kudos
6 Replies
Altera_Forum
Honored Contributor II
2,948 Views

You just need to associate the clock port to the reset port. This is done in component editor. You can also hack the tcl file by putting the clock port name in between the quotes in this line: 

 

set_interface_property clock_reset associatedClock "" 

 

The same thing will need to be done for all of the interfaces since Qsys uses this information to determine if reset syncronization or clock crossing is necessary for your interfaces.
0 Kudos
Altera_Forum
Honored Contributor II
2,948 Views

Hi BadOmen, 

 

thanks for the answer. 

 

Due to an other project I had to care of, today, I havn't had the chance to see if this solves my problem. I will do that tomorrow. 

 

I'm wondering if a later version of QSYS will produce valid TCL files for custom components for that kind of entity definition I have in my example. Or are there many additions/changes in QSYS compared to SOPC that I have to re-learn the whole Avalon specification? 

 

I would not like to define avalon compatible entity definitions and then have to go to the TCL file to fix something. If I have to, then I think it's not worth to use the custom component wizzard. 

 

If there is actually something missing in my entity definition that is new in QSYS, can you please point me to the correct Altera documentation that I can update my knowledge of the Avalon specification? 

 

Thanks, 

Maik
0 Kudos
Altera_Forum
Honored Contributor II
2,948 Views

You shouldn't have to change anything in your HDL, the missing clock assignments are just a problem with the .tcl file. When you were creating the interface definitions in component editor did you remember to assign the clock interface to all your slave, reset, and interrupt ports? Also I just noticed the association of the interrupt interface is missing (you need to associate it to the slave port). If you were expecting the tools to do this automatically then that might explain why you ran into this (the tools don't know what your intentions are so you need to do that manually).

0 Kudos
Altera_Forum
Honored Contributor II
2,948 Views

Hi BadOmen, 

 

you are right, I did not assigne the clock interface to my reset port. I think I haacvn't done that beause I never did that in SOPC. I think I have to update and deepen my understanding of the SOPC/QSYS custom component creation process. 

 

My current problem right now is, that one of my own I2C components does not go throught bthe component editor because it does not provide a reset input. I think I can solve this problem by just providing one but I had no problems in SOPC with that entity definition. 

 

Is there some kind of change documentation between QSYS and SOPC so that I can see what is newly required by QSYS? What is your suggested way of getting started with QSYS? It seems that I have to start from page one of the QSYS documentation because I guess there are many new features and rules that I have to know of instead of doing it the trial and error way. . .  

 

Why, for example, is it mandatory to define a reset interface port? I thought it is the descision of the designer if he needs a reset, or not? 

 

Also, why does the component editor have to know if the reset is associated with the clock? I mean, in the past (in SOPC) it seemed, that the designer was responsible to define in the architecture (in VHDL) the handling of the interface signals. Why has that changed? Or am I thinking in the wrong direction, here? 

 

Thanks, 

Maik
0 Kudos
Altera_Forum
Honored Contributor II
2,948 Views

sorry, double entry . . . .

0 Kudos
Altera_Forum
Honored Contributor II
2,948 Views

In general there is no document that describes at a fine detail the differences between the tools. There is an upgrade doc that goes over what will not work when upgrading that might be worth reading. I think it's called the "SOPC Builder to Qsys migration guide". I'm surprised SOPC Builder let you get away with not having a reset port but if you have a component that doesn't have a reset (poor design practice if you ask me) then you would just include one and leave it hanging. What I have been finding is that Qsys is just more strick about what it lets you get away with. 

 

Matching up the clock domain to the various ports is something dictated by the component .tcl API so unless you are bringing in old components that were .ptf based (Quartus v6.1 or earlier) then component editor should have been asking you to associate the ports to a clock domain even in SOPC Builder. Perhaps SOPC Builder just assumes with single clock components that everything must be on that domain. If that's the case it's good that Qsys doesn't let you get away with that since telling the tools what clock domain your interfaces operate on is something you should do and not the tools automatically.
0 Kudos
Reply