Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,022 Views

How to handle complex external signals in Qsys

It seems that in Qsys, it is not possible to export any signal that is not STD_LOGIC or STD_LOGIC_VECTOR (or a SUBTYPE thereof). Is this correct ? 

 

We have a slave that exports a bunch of these in a RECORD, to minimize the coding effort (and risk of making errors) to connect them to other subsystems in the FPGA. There's a post on this forum back in 2009 where this was already discussed for SOPC Builder and the suggestions was to use a function to mux/demux these signals to SL(V)s and back. Before embarking on this journey, I'd like to make sure I haven't overlooked anything. 

 

Thanks, 

 

J.
0 Kudos
4 Replies
Altera_Forum
Honored Contributor I
28 Views

Right, Qsys only handles std_logic or std_logic_vector. This basically stems from the fact that Qsys (and SOPC) is 'Verilog' (which doesn't have a 'record' construct).  

I code 'to_std_logic_vector( r_type : r)' and 'to_r_type( v : std_logic_vector)' functions for every record I create. The record definition has to go in a package anyway, so including the two functions makes connecting Qsys components easy.
Altera_Forum
Honored Contributor I
28 Views

Ok. Exactly what I was looking for. 

 

I did observe that the Qsys component _hw.tcl files have the SLV width hardcoded. I take it you regenerate them all somehow when you change your records ?
Altera_Forum
Honored Contributor I
28 Views

Changing records inevitably leads to regeneration of the _hw.tcl  

You can automate that if you add an elaborate() call and inside that read your package.vhd to adjust the width of the SLV's. Actually it is a bit of fun ;) and it would be even more fun if we could have Python in stead of Tcl :(
Altera_Forum
Honored Contributor I
28 Views

Ok. Thanks for your help !

Reply