Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

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.

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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 :(