Brian Padalino wrote:
> There should be absolutely no glue logic between the modules within a
> top entity possibly called mblock_processing. The inputs should feed
> the specialized USB FIFOs, and the outputs should feed the separate
> CIC channel filters (complex).
>
> Everything else from there should be straight forward with strobing
> samples in and out.
>
Yes, that's what I wanted to say :)
>> A what rate should I send the samples to the tx_chains? Every 4 clock
>> cycles? They seems to be controlled by tx_strobe, but I failed to
>> understand what this signal actually mean.
>
> The minimum interpolation rate is 4 due to the CIC filter limitations,
> so once every 4 will yield one side of the spectrum. I believe 128 is
> the other end of the spectrum, but you should set a constant for the
> rate so we can test with different ones.
Ok, so my usb_chan_reader needs some more work to handle that. I will
try to get this and some of the missing functionalities like reporting
overrun/underrun done tomorrow.
> The tx_strobe happens once every rate clock cycles - with which it
> will send in a new sample. That strobe sends a new value down the TX
> stream and reads a new one ready for the next tx_strobe.
>
>> What is the point of the bus_reset and the clear_status signal? They are
>> both input to current tx_buffer.
>
> I am not sure of this - but I am assuming to stop/reset the transmit
> path and clear any status messages respectively. :) I'll try to have
> a look at the code and find out more later.
>
Thanks.
>> As we report overrun/underrun in packet header, are we gonna get rid of
>> the tx_empty, have_space and tx_underrun signal ?
>
> have_space is used by the feeding FX2 to know if the FPGA can handle
> one more packet. This signal shouldn't go anywhere. The other
> signals should probably stick around for now.
>
>> Comments on the code I checked in are welcome...
>
> I'll look it over this weekend and give comments and feedback.
>
That would be awesome :)
> Brian
>
Thibaud
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
