Prev: repeting outputs of counter
Next: Register Now: FPGA Camp Bangalore, INDIA. May'21
From: Sharath Raju on 11 May 2010 00:32
Hi,

I am trying to implement autocorrelation operation on an FPGA.
Autocorrelation can be written as: Phi(n) = Summation { x(k) * x(n-
k) }
Essentially, the signal x(k) is multiplied with a delayed version of
itself and the product is accumulated over a finite range of x(k)
samples.

I have written VHDL code, where the delay, multiply and accumulate
operations are carried out sequentially at the rising edge of the
clock.

{link to code http://sites.google.com/site/brsharath/sdmac_approach0_1.vhd?attredirects=0&d=1
}

In the clock process, I expect the statements within the "if block" to
execute sequentially. However, in the RTL description,

{link
http://5483477158486903344-a-1802744773732722657-s-sites.googlegroups.com/site/brsharath/sdmac_approach0_1.png?attachauth=ANoY7cp-FCHAwKIai7JuTsVPgvAENU4ou15FLhplgwxKlODHsz3G3sNsTOC2xPAoaNE8IntPEYP7T9A76ACM5Ry9o6rRLdbvVtI0nVThp84mEtGt6bGuw2RmVcTG9sEmAQ2ULQXNYqR4xlihAZlDayHEaw7u-PsfE4HqAbgtr8fRUFm22PjwSkiLrtj5rMvP5WyDwMGxA31ByVc3sdISyWa1fQClsMXTlw%3D%3D&attredirects=0}
it is seen that the adder and output D flip-flop of the multiplier
triggered by the same clock signal, without any delay between the two.
This causes the adder block to operate even before the multiplier
output reaches the adder input. Why is this so ? Further, in the
functional simulation, I see that the output of the DMAC unit is
updated after two clock cycles. My requirement is that the delay,
multiply and accumulate operations happen sequentially and within the
same clock cycle.

If the above description is not clear, please let me know, I may be
able to explain in a simpler manner.

Thanks,
Sharath
From: backhus on 11 May 2010 02:31
On 11 Mai, 06:32, Sharath Raju <brshar...(a)gmail.com> wrote:
> Hi,
>
> I am trying to implement autocorrelation operation on an FPGA.
> Autocorrelation can be written as: Phi(n) = Summation { x(k) * x(n-
> k) }
> Essentially, the signal x(k) is multiplied with a delayed version of
> itself and the product is accumulated over a finite range of x(k)
> samples.
>
> I have written VHDL code, where the delay, multiply and accumulate
> operations are carried out sequentially at the rising edge of the
> clock.
>
> {link to codehttp://sites.google.com/site/brsharath/sdmac_approach0_1.vhd?attredir...
>
> }
>
> In the clock process, I expect the statements within the "if block" to
> execute sequentially. However, in the RTL description,
>
> {linkhttp://5483477158486903344-a-1802744773732722657-s-sites.googlegroups...}
>  it is seen that the adder and output D flip-flop of the multiplier
> triggered by the same clock signal, without any delay between the two.
> This causes the adder block to operate even before the multiplier
> output reaches the adder input.  Why is this so ? Further, in the
> functional simulation, I see that the output of the DMAC unit is
> updated after two clock cycles. My requirement is that the delay,
> multiply and accumulate operations happen sequentially and within the
> same clock cycle.
>
> If the above description is not clear, please let me know, I may be
> able to explain in a simpler manner.
>
> Thanks,
> Sharath

Hi Sharath,
I wonder that your code synthesizes at all.
Normally a process with two different clock triggers (rising edge and
falling edge) would cause an error,
Maybe you got luck, because your signal del_2_x doesn't appear in the
other clock region.
Anyway, this half clock delay is unnecessary. Make it a full cycle or
leave it away.

Also you have no reset scheme, just default assignments in the
declarations.
Xilinx ISE can handle that, but other tools ignore it.


Now to your implementation, do you know about pipelining?
This is what's happening in your code. It's nothing bad, just
something to be considered.
Remember the driver/reader concept of VHDL signals?
So when you are assigning to some signal ,the value is writen to the
signals driver, but other assignments that use this signal in the same
process take the old value from the signals reader.
Every assignment in a clocked process creates a register, so you have
to take care that your datapath has proper delays for all signals, to
put the right data at the right time at the inputs of yor arithmetic
operators.
Did you make a time schedule plan for your data? There you can see
which signals need extra delay

Have a nice simulation
Eilert

From: Christopher Head on 11 May 2010 03:11
On Mon, 10 May 2010 23:31:23 -0700 (PDT)
backhus <goouse99(a)googlemail.com> wrote:

[snip]
> Also you have no reset scheme, just default assignments in the
> declarations.
> Xilinx ISE can handle that, but other tools ignore it.
[snip]

Sorry for hijacking the thread, but... do you mean that if I write this
code:

signal foo : std_ulogic_vector(3 downto 0) := "1010";

I would *not* normally expect the FPGA to power up with "1010" in the
signal!? I've only ever worked with Xilinx FPGAs using ISE, so I
assumed it worked everywhere; is this not the case? (kind of nice to
know in case I do some day end up using a different make of FPGA...)

Chris
From: backhus on 12 May 2010 01:45
On 11 Mai, 09:11, Christopher Head <ch...(a)cs.ubc.ca> wrote:
> On Mon, 10 May 2010 23:31:23 -0700 (PDT)
>
> backhus <goous...(a)googlemail.com> wrote:
>
> [snip]> Also you have no reset scheme, just default assignments in the
> > declarations.
> > Xilinx ISE can handle that, but other tools ignore it.
>
> [snip]
>
> Sorry for hijacking the thread, but... do you mean that if I write this
> code:
>
> signal foo : std_ulogic_vector(3 downto 0) := "1010";
>
> I would *not* normally expect the FPGA to power up with "1010" in the
> signal!? I've only ever worked with Xilinx FPGAs using ISE, so I
> assumed it worked everywhere; is this not the case? (kind of nice to
> know in case I do some day end up using a different make of FPGA...)
>
> Chris

Hi Chris,
That's right.
The synthesis standard for VHDL treats assignments at declaration time
as "ignored".
They work and are intended to use for simulation (e.g. in
testbenches).

That XST uses these values is due to the fact that they can be held in
the programming bitstream, and thus be present at power up for an SRAM
based FPGA.
Think of ASICs (or antifuse FPGAs) and this is no more true, so, as
Neal mentioned, your code isn't portable anymore.
Same is if you use a tool that strictly complies with the VHDL
simulation standard.

I didn't mention how to solve the problem, because that's a tricky
question.
It depends on many things whether you should do it, and how to do it.
e.g.
Registers in datapaths don't necessarily need a reset. The values are
continuously overwritten.
BUT:
If you have a feedback path your simulation can stuck with 'X'es.
One possible solution is to create Registers with an asynchronous
reset, that will be used by ths testbench, and tied to the inactive
state for synthesis.
So the net will be optimized away and there are no 'X'es in a real
chip. :-)

For Counters/FSMs and such you have to decide.
e.g.: A loadable counter doesn't need a reset, if the first thing that
happens is a load operation.
Also you should think about asynchronous and synchronous resets.

A nice paper about this topic can be found on the Xilinx website.

Have a nice synthesis
Eilert
From: Sharath Raju on 12 May 2010 04:49
On May 12, 10:45 am, backhus <goous...(a)googlemail.com> wrote:
> On 11 Mai, 09:11, Christopher Head <ch...(a)cs.ubc.ca> wrote:
>
>
>
> > On Mon, 10 May 2010 23:31:23 -0700 (PDT)
>
> > backhus <goous...(a)googlemail.com> wrote:
>
> > [snip]> Also you have no reset scheme, just default assignments in the
> > > declarations.
> > > Xilinx ISE can handle that, but other tools ignore it.
>
> > [snip]
>
> > Sorry for hijacking the thread, but... do you mean that if I write this
> > code:
>
> > signal foo : std_ulogic_vector(3 downto 0) := "1010";
>
> > I would *not* normally expect the FPGA to power up with "1010" in the
> > signal!? I've only ever worked with Xilinx FPGAs using ISE, so I
> > assumed it worked everywhere; is this not the case? (kind of nice to
> > know in case I do some day end up using a different make of FPGA...)
>
> > Chris
>
> Hi Chris,
> That's right.
> The synthesis standard for VHDL treats assignments at declaration time
> as "ignored".
> They work and are intended to use for simulation (e.g. in
> testbenches).
>
> That XST uses these values is due to the fact that they can be held in
> the programming bitstream, and thus be present at power up for an SRAM
> based FPGA.
> Think of ASICs (or antifuse FPGAs) and this is no more true, so, as
> Neal mentioned, your code isn't portable anymore.
> Same is if you use a tool that strictly complies with the VHDL
> simulation standard.
>
> I didn't mention how to solve the problem, because that's a tricky
> question.
> It depends on many things whether you should do it, and how to do it.
> e.g.
> Registers in datapaths don't necessarily need a reset. The values are
> continuously overwritten.
> BUT:
>   If you have a feedback path your simulation can stuck with 'X'es.
> One possible solution is to create Registers with an asynchronous
> reset, that will be used by ths testbench, and tied to the inactive
> state for synthesis.
> So the net will be optimized away and there are no 'X'es in a real
> chip. :-)
>
> For Counters/FSMs and such you have to decide.
> e.g.: A loadable counter doesn't need a reset, if the first thing that
> happens is a load operation.
> Also you should think about asynchronous and synchronous resets.
>
> A nice paper about this topic can be found on the Xilinx website.
>
> Have a nice synthesis
>    Eilert

On May 11, 1:24 pm, "Nial Stewart"
<nial*REMOVE_TH...(a)nialstewartdevelopments.co.uk> wrote:
> > Sorry for hijacking the thread, but... do you mean that if I write this
> > code:
> > signal foo : std_ulogic_vector(3 downto 0) := "1010";
> > I would *not* normally expect the FPGA to power up with "1010" in the
> > signal!? I've only ever worked with Xilinx FPGAs using ISE, so I
> > assumed it worked everywhere; is this not the case? (kind of nice to
> > know in case I do some day end up using a different make of FPGA...)
>
> You shouldn't rely in this if you want your designs to be 'portable'.
>
> You should also think about active reset logic for your design so that
> you know everything will definitely power up to a known state. What
> happens if you have a portion of your design you want to hold in reset
> until something else is configured properly?
>
> I have done this to allow a quick simulation of a module and
> know that Quartus throws up a warning (although I'm not sure if it does actually
> implement the reset value).
>
> Bottom line is you need a reset mechanism in to set these values.
>
> Nial.

Thanks for all the inputs, particularly bachus.

I paid careful attention to the signal driver concept, and rewrote the
code {link: http://sites.google.com/site/brsharath/sdmac_signal_sched.vhd?attredirects=0&d=1
}

The resulting RTL schematic is posted here: {link:http://
5483477158486903344-a-1802744773732722657-s-sites.googlegroups.com/
site/brsharath/RTL.png?
attachauth=ANoY7coSXbMoJLHb5mbgwSAjgt3QN8FYgvT7itNF1lC3peoLOlSNRh7dgnAlxJClWwXFP8uTl6q387V0zZBmAdQIH5F79SuOJV9mtBqSiAR0s0dCCeGvDqrI-
JlaMoF6x5YETpEBkFYsEPFvVwDq-YKMLvzfo-
r8wz0ByGeZAHE7DP_rFJKDcEFTzDm2ez4o_2m8OlDzqFR5&attredirects=0 }
Please have a look and let me know if you have something to say. The
clock updates in the same clock cycle, without any delay.

However, I did not understand what you mean by a Reset scheme and a
time schedule plan. Are you simply referring to having an idea about
"which signals should change when and under what conditions" ?

Thanks,
Sharath
 |  Next  |  Last
Pages: 1 2
Prev: repeting outputs of counter
Next: Register Now: FPGA Camp Bangalore, INDIA. May'21