Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 139725

Article: 139725
Subject: Re: Strange order of BRAM data bus connections
From: rickman <gnuarm@gmail.com>
Date: Fri, 10 Apr 2009 13:13:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
Take a look at your numbering.  On bram X, bit 15 is connected to bit
11.  On bram Y bit 11 is connected to bit 15.  You don't have a logic
problem, you have a nomenclature problem.  You are permuting the buses
in different ways on the two sides.

Rick

Article: 139726
Subject: Re: Strange order of BRAM data bus connections
From: gabor <gabor@alacron.com>
Date: Fri, 10 Apr 2009 13:20:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 10, 1:17=A0pm, aleksa <aleks...@gmail.com> wrote:
> I'm using two dual port BRAMs to connect a 16-bit CPU
> to a 1-bit serial flash (AT45DB161D).
>
> Flash side: 4096*1
> CPU =A0 side: 256*16 (512 bytes)
>
> BRAM X is used to transmit data from CPU to FLASH, and
> BRAM Y from FLASH to CPU.
>
> I've connected the CPU data bus like this:
>
> BRAM X
> DBUS(8) ... DBUS(15), DBUS(0) .. DBUS(7)
>
> BRAM Y
> 8 ... 15, 0 .. 7 (ie. the same)
>
> Both reading and writing works fine.
>
> However, for security reasons,
> I wish to scramble the bus:
>
> BRAM X
> 12, 1, 6, 9, 15, 4, 14, 7, 2, 5, 8, 11, 3, 10, 0, 13.
>
> (all 16 DBUS bits, just not in order)
>
> I presumed the BRAM Y should have the same DBUS
> order, but then reading gets invalid data.
> After some trial and error, I've found the required
> order on the BRAM Y:
>
> 11, 9, 0, 15, 4, 2, 12, 5, 8, 13, 6, 10, 3, 7, 14, 1.
>
> Can anyone explain why is the order of DBUS
> on BRAM X & Y the same in the first case
> and not in the second one?
>
> All buses are std_logic_vector(15 downto 0)

umm...

You realize you need to do the reverse function
for the return data?

i.e. for the first case you have:
0 -- 0
1 -- 1
2 -- 2
. . .
15 -- 15

so of course the reverse function is the same as the
original.

Now you have:
12 -- 15
 1 -- 14
 6 -- 13
 9 -- 12
15 -- 11
 4 -- 10
14 --  9
 7 --  8
 2 --  7
 5 --  6
 8 --  5
11 --  4
 3 --  3
10 --  2
 0 --  1
13 -- 0

So using the numbers on the left to find the bit you
want on the right gives you

15 -- 11
14 --  9
13 --  0
12 -- 15
11 --  4
10 --  2
 9 -- 12
 8 --  5
 7 --  8
 6 -- 13
 5 --  6
 4 -- 10
 3 --  3
 2 --  7
 1 -- 14
 0 --  1

by simply sorting the table using the left column.

Regards,
Gabor

Article: 139727
Subject: Re: Strange order of BRAM data bus connections
From: aleksa <aleksaZR@gmail.com>
Date: Fri, 10 Apr 2009 13:36:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 10, 10:13=A0pm, rickman <gnu...@gmail.com> wrote:
> Take a look at your numbering. =A0On bram X, bit 15 is connected to bit
> 11. =A0On bram Y bit 11 is connected to bit 15. =A0You don't have a logic
> problem, you have a nomenclature problem. =A0You are permuting the buses
> in different ways on the two sides.
>
> Rick

Rick, thank you very much, I get it now.

Article: 139728
Subject: Re: Strange order of BRAM data bus connections
From: aleksa <aleksaZR@gmail.com>
Date: Fri, 10 Apr 2009 13:42:33 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 10, 10:20=A0pm, gabor <ga...@alacron.com> wrote:
> On Apr 10, 1:17=A0pm, aleksa <aleks...@gmail.com> wrote:
>
>
>
>
>
> > I'm using two dual port BRAMs to connect a 16-bit CPU
> > to a 1-bit serial flash (AT45DB161D).
>
> > Flash side: 4096*1
> > CPU =A0 side: 256*16 (512 bytes)
>
> > BRAM X is used to transmit data from CPU to FLASH, and
> > BRAM Y from FLASH to CPU.
>
> > I've connected the CPU data bus like this:
>
> > BRAM X
> > DBUS(8) ... DBUS(15), DBUS(0) .. DBUS(7)
>
> > BRAM Y
> > 8 ... 15, 0 .. 7 (ie. the same)
>
> > Both reading and writing works fine.
>
> > However, for security reasons,
> > I wish to scramble the bus:
>
> > BRAM X
> > 12, 1, 6, 9, 15, 4, 14, 7, 2, 5, 8, 11, 3, 10, 0, 13.
>
> > (all 16 DBUS bits, just not in order)
>
> > I presumed the BRAM Y should have the same DBUS
> > order, but then reading gets invalid data.
> > After some trial and error, I've found the required
> > order on the BRAM Y:
>
> > 11, 9, 0, 15, 4, 2, 12, 5, 8, 13, 6, 10, 3, 7, 14, 1.
>
> > Can anyone explain why is the order of DBUS
> > on BRAM X & Y the same in the first case
> > and not in the second one?
>
> > All buses are std_logic_vector(15 downto 0)
>
> umm...
>
> You realize you need to do the reverse function
> for the return data?

I didn't realize that..

The one-to-one order in the first sample
made me believe that it is really simple!


>
> i.e. for the first case you have:
> 0 -- 0
> 1 -- 1
> 2 -- 2
> . . .
> 15 -- 15
>
> so of course the reverse function is the same as the
> original.
>
> Now you have:
> 12 -- 15
> =A01 -- 14
> =A06 -- 13
> =A09 -- 12
> 15 -- 11
> =A04 -- 10
> 14 -- =A09
> =A07 -- =A08
> =A02 -- =A07
> =A05 -- =A06
> =A08 -- =A05
> 11 -- =A04
> =A03 -- =A03
> 10 -- =A02
> =A00 -- =A01
> 13 -- 0
>
> So using the numbers on the left to find the bit you
> want on the right gives you
>
> 15 -- 11
> 14 -- =A09
> 13 -- =A00
> 12 -- 15
> 11 -- =A04
> 10 -- =A02
> =A09 -- 12
> =A08 -- =A05
> =A07 -- =A08
> =A06 -- 13
> =A05 -- =A06
> =A04 -- 10
> =A03 -- =A03
> =A02 -- =A07
> =A01 -- 14
> =A00 -- =A01
>
> by simply sorting the table using the left column.
>
> Regards,
> Gabor- Hide quoted text -
>
> - Show quoted text -

Thank you for the sort idea

Article: 139729
Subject: Avnet spartan 3A design issue
From: axr0284 <axr0284@yahoo.com>
Date: Fri, 10 Apr 2009 13:44:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,
 I have been trying to understand the reason for the flash addressing
scheme in the example design
Avt3S400A_Eval_MB_parallel_flash_v10_1_01. The flash chip used is
S29GL032N.


1) It seems that the design is using a 2Mx16Bits flash. but the
accessible address of the core is set to 4M in the xps address
section. Is that suppose to be in bytes? I thought that the PLB bus
supports 32 bits so shouldn't the address base be based on 32 bits.


2) On top of that, it seems that the PLB 32 bit address is going
through a bus splitter and then address bits 10 to 30 is sent to the
flash core. Can anybody explain why that is the case?


3) The address setup is 0x84c00000 to 84FFFFFF. Does that mean if I
write to address 0x84C00000, it will be mapped to address 0 and
0x84C00002 will be sent to address 1 on the Flash.


I am really confused about this. I hope someone who has tried this can
help me out.

Project files located at
http://www.em.avnet.com/evk/home/0,4534,CID%253D46501%2526CCD%253DUSA%2526SID%253D32214%2526DID%253DDF2%2526LID%253D32232%2526BID%253DDF2%2526CTP%253DEVK,00.html?SUL=spartan3a-evl

Thanks,
Amish



Article: 139730
Subject: Re: Programming Digilent Nexys 2 from Linux
From: John Eaton <nospam@spam.com>
Date: Fri, 10 Apr 2009 14:51:45 -0700
Links: << >>  << T >>  << A >>
Andy Ross wrote:

> 
> Hopefully this will help other newbies with the learning curve.  Let
> me know if something doesn't work, or if there are questions.





< bitgen ${PROJ}_par.ncd $PROJ.bit $PROJ.pcf
---
 > bitgen $PROJ_par.ncd $PROJ.bit $PROJ.pcf

Article: 139731
Subject: Re: NCO'S
From: "Marty Ryba" <martin.ryba.nospam@verizon.net>
Date: Sat, 11 Apr 2009 02:02:36 GMT
Links: << >>  << T >>  << A >>
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message 
news:tgkut49k75rk4p3g2rea40ee2gjfk6oacn@4ax.com...
> On Fri, 10 Apr 2009 05:49:23 -0700 (PDT), "Naveen........."
> <kumarg.naveen@gmail.com> wrote:
>>im doing a project where i have to implement nco in spartan-2
>>xc2s30....
>>please give me a solution for below mentioned problem at the earliest
>>i need code for 48 bit nco in vhdl where i should provide clock of
>>120Mhz frm fpga which works at 66Mhz.
>>i know to divide clock using d-flipflop but not familiar in
>>multiplying the clock...
> You _are_ aware of the on-chip clock doublers (DLLs)?
> As mentioned in Xilinx appnote XAPP174?
> And if you're creating an NCO, presumably it's no problem
> if its source clock is 132MHz rather than 120MHz - just
> re-scale everything...

Actually, by the Nyquist theorem, you have to have an input clock of at 
least 2X your desired output frequency. Your digital clock is mathematically 
equivalent to Y = sign(sin(tune*f_clock/2^48))) where "tune" is your 48 bit 
(that's a lot of bits!) unsigned "tune word." Now, values of tune/2^N that 
are over 1/2 are equivalent to negative frequencies, so the highest absolute 
frequency you can get is +- f_clock/2.

So, to get 120 MHz, you'll want something approaching 300 MHz or more input 
(what is this feeding? what kind of filtering/jitter specification do you 
have?). Getting a 48-bit non-pipelined (you need the new value every clock) 
accumulator to run at 300 MHz in a S3 is probably well nigh impossible (I'll 
defer to the experts).

Think through your requirements carefully, and then you can go further. For 
instance, you may (at the loss of resolution) be able to create a lower 
frequency clock, clean it up in some kind of filter, and then feed that into 
the DCMs to double (or more) the frequency to where you need it. You can 
also use a DAC if you want sine waves (send more bits to the DAC), and then 
pick one of the higher harmonics as long as your circuitry (or the DAC) 
doesn't filter them out.

-Marty 



Article: 139732
Subject: Re: NCO'S
From: rickman <gnuarm@gmail.com>
Date: Fri, 10 Apr 2009 19:58:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 10, 10:02=A0pm, "Marty Ryba" <martin.ryba.nos...@verizon.net>
wrote:
> "Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote in message
>
> news:tgkut49k75rk4p3g2rea40ee2gjfk6oacn@4ax.com...
>
> > On Fri, 10 Apr 2009 05:49:23 -0700 (PDT), "Naveen........."
> > <kumarg.nav...@gmail.com> wrote:
> >>im doing a project where i have to implement nco in spartan-2
> >>xc2s30....
> >>please give me a solution for below mentioned problem at the earliest
> >>i need code for 48 bit nco in vhdl where i should provide clock of
> >>120Mhz frm fpga which works at 66Mhz.
> >>i know to divide clock using d-flipflop but not familiar in
> >>multiplying the clock...
> > You _are_ aware of the on-chip clock doublers (DLLs)?
> > As mentioned in Xilinx appnote XAPP174?
> > And if you're creating an NCO, presumably it's no problem
> > if its source clock is 132MHz rather than 120MHz - just
> > re-scale everything...
>
> Actually, by the Nyquist theorem, you have to have an input clock of at
> least 2X your desired output frequency. Your digital clock is mathematica=
lly
> equivalent to Y =3D sign(sin(tune*f_clock/2^48))) where "tune" is your 48=
 bit
> (that's a lot of bits!) unsigned "tune word." Now, values of tune/2^N tha=
t
> are over 1/2 are equivalent to negative frequencies, so the highest absol=
ute
> frequency you can get is +- f_clock/2.
>
> So, to get 120 MHz, you'll want something approaching 300 MHz or more inp=
ut
> (what is this feeding? what kind of filtering/jitter specification do you
> have?). Getting a 48-bit non-pipelined (you need the new value every cloc=
k)
> accumulator to run at 300 MHz in a S3 is probably well nigh impossible (I=
'll
> defer to the experts).
>
> Think through your requirements carefully, and then you can go further. F=
or
> instance, you may (at the loss of resolution) be able to create a lower
> frequency clock, clean it up in some kind of filter, and then feed that i=
nto
> the DCMs to double (or more) the frequency to where you need it. You can
> also use a DAC if you want sine waves (send more bits to the DAC), and th=
en
> pick one of the higher harmonics as long as your circuitry (or the DAC)
> doesn't filter them out.

Nyquist doesn't necessarily apply here.  If you are trying to toggle
an output on the edges of a clock, then yes, Nyquist defines the max
rate.  But an NCO can operate by generating a clock enable.  In that
case the enable can be active on any and all clock cycles producing
clock rates up to the clock frequency.

It depends on how you are using the output.

Rick

Article: 139733
Subject: Getting efficient logic synthesis
From: rickman <gnuarm@gmail.com>
Date: Fri, 10 Apr 2009 20:55:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am trying to get an optimum usage of LUTs in a basic mux.  I think
the part that is confusing the tool is that I am trying to save LUTs
by using the unused input on the first LUT as an enable.  The tool
seems bright enough to combine two LUT4s into a 4 to 1 mux using the
extra logic for that provided in the slice.  But it looses any idea of
what to do with the unused input.

Here is the code for the 4 to 1 mux with enable.

  with DatSel (1 downto 0) select  MuxLft <= -- 2 * DAWTH LUTs
	DatLog	and (DAWTH-1 downto 0 => not DatSel(2))	when "00",
	MemRdDat and (DAWTH-1 downto 0 => not DatSel(2))	when "01",
	DatAdd	and (DAWTH-1 downto 0 => not DatSel(2))	when "10",
	ShftDat	and (DAWTH-1 downto 0 => not DatSel(2))	when "11",
	resize("0", DAWTH)							when others;

I have two of these and a third which is just a 2 to 1 mux.  The two 4
to 1 muxes are or'ed (since they are already enabled by select bit 2)
and muxed with the 2 to 1 mux output in another level of LUTs.

  DatMux <= MuxLft or MuxRgt when DatSel (3) = '0' else MuxHigh;

The tool (Synplicity) seems intent in making this much more complex
than it needs to be.  Mostly it seems to want to push the enable
through to additional logic after the first mux.

It just seems like the tool is working very hard to produce a non-
optimal solution.  This is  not much different from the adders where
it duplicates the sum output of the first bit using extra logic
instead of just using the bit from the adder chain which has to be
calculated anyway to determine the carry into the second bit.

Is this a problem with Synplify?

Rick

Article: 139734
Subject: Re: Avnet spartan 3A design issue
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Fri, 10 Apr 2009 22:44:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 10, 11:44=A0pm, axr0284 <axr0...@yahoo.com> wrote:
> Hi,
> =A0I have been trying to understand the reason for the flash addressing
> scheme in the example design
> Avt3S400A_Eval_MB_parallel_flash_v10_1_01. The flash chip used is
> S29GL032N.
>
> 1) It seems that the design is using a 2Mx16Bits flash. but the
> accessible address of the core is set to 4M in the xps address
> section. Is that suppose to be in bytes? I thought that the PLB bus
> supports 32 bits so shouldn't the address base be based on 32 bits.
>
byte addressing

> 2) On top of that, it seems that the PLB 32 bit address is going
> through a bus splitter and then address bits 10 to 30 is sent to the
> flash core. Can anybody explain why that is the case?
>

WRONG endian !!!

bit 31 is least significant bit.
you are gonna see this a lot more when working with EDK

> 3) The address setup is 0x84c00000 to 84FFFFFF. Does that mean if I
> write to address 0x84C00000, it will be mapped to address 0 and
> 0x84C00002 will be sent to address 1 on the Flash.
>

correct, 0ffset 0x02 maps to address 1 of 16 bit wide ext memory

> I am really confused about this. I hope someone who has tried this can
> help me out.
>
> Project files located athttp://www.em.avnet.com/evk/home/0,4534,CID%253D4=
6501%2526CCD%253DUSA...
>
> Thanks,
> Amish


Article: 139735
Subject: Re: S3A starterkit weird behaviou (mini quiz)
From: Arnim <clv.5.minral@spamgourmet.com>
Date: Sat, 11 Apr 2009 09:07:31 +0200
Links: << >>  << T >>  << A >>
> now the funny thing comes:
> 
> there are two different possibilities for the LEDs depening the slide
> switch (reset!)
> this is normal (reset and run states)
> 
> but there is also 3rd possibility when the LEDs are about 50% of
> intensity!!

Which position is the switch then - reset or run?

What's the state of the LEDs during reset? What after reset, i.e. the
next pattern?

> what is the reason? how come the LEDs be at 50% intensity?
> FPGA is configured all the time, the leds are driven with constant
> value. (no PWM)

First guess: 50% intentsity is caused by the design looping
reset->run->reset->run. I'd investigate for ground bounce affecting the
reset input. A weak pull-up is probably also involved.

Arnim

Article: 139736
Subject: Re: S3A starterkit weird behaviou (mini quiz)
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sat, 11 Apr 2009 00:12:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 11, 10:07=A0am, Arnim <clv.5.min...@spamgourmet.com> wrote:
> > now the funny thing comes:
>
> > there are two different possibilities for the LEDs depening the slide
> > switch (reset!)
> > this is normal (reset and run states)
>
> > but there is also 3rd possibility when the LEDs are about 50% of
> > intensity!!
>
> Which position is the switch then - reset or run?
>
> What's the state of the LEDs during reset? What after reset, i.e. the
> next pattern?
>
> > what is the reason? how come the LEDs be at 50% intensity?
> > FPGA is configured all the time, the leds are driven with constant
> > value. (no PWM)
>
> First guess: 50% intentsity is caused by the design looping
> reset->run->reset->run. I'd investigate for ground bounce affecting the
> reset input. A weak pull-up is probably also involved.
>
> Arnim

100% hit (i was just curious if somebody guesses it)

yes that it was, the slide switch was in middle position
there is no onboard resistor and fpga pulls disabled

it worked also like CAPACITIVE touch sensor
touching PCB at LED0 (close to the switch) made leds on, taking finger
away led off

Antti




Article: 139737
Subject: Re: S3A starterkit weird behaviou (mini quiz)
From: Arnim <clv.5.minral@spamgourmet.com>
Date: Sat, 11 Apr 2009 09:50:19 +0200
Links: << >>  << T >>  << A >>

>> First guess: 50% intentsity is caused by the design looping
>> reset->run->reset->run. I'd investigate for ground bounce affecting the
>> reset input. A weak pull-up is probably also involved.
> 
> 100% hit (i was just curious if somebody guesses it)
> 
> yes that it was, the slide switch was in middle position
> there is no onboard resistor and fpga pulls disabled
> 
> it worked also like CAPACITIVE touch sensor
> touching PCB at LED0 (close to the switch) made leds on, taking finger
> away led off

Ouch :-)
Resets can be as troublesome as clocks. We once debugged a sporadically
failing board only to find that the reset input of the central chip
glitches from time to time (cross-talk from other PCB traces). Even if
the wire was clamped to supply rail. Only workaround was to clip off the
respective pin (PGA) since we didn't need it at all.

People argued whether it was bad PCB design (no shielding of async
signal) or bad chip design (no low-pass filter at async input). I'd say
both :-)

Arnim

Article: 139738
Subject: Re: S3A starterkit weird behaviou (mini quiz)
From: "kadhiem_ayob" <kadhiem_ayob@yahoo.co.uk>
Date: Sat, 11 Apr 2009 04:20:06 -0500
Links: << >>  << T >>  << A >>
>
>>> First guess: 50% intentsity is caused by the design looping
>>> reset->run->reset->run. I'd investigate for ground bounce affecting
the
>>> reset input. A weak pull-up is probably also involved.
>> 
>> 100% hit (i was just curious if somebody guesses it)
>> 
>> yes that it was, the slide switch was in middle position
>> there is no onboard resistor and fpga pulls disabled
>> 
>> it worked also like CAPACITIVE touch sensor
>> touching PCB at LED0 (close to the switch) made leds on, taking finger
>> away led off
>
>Ouch :-)
>Resets can be as troublesome as clocks. We once debugged a sporadically
>failing board only to find that the reset input of the central chip
>glitches from time to time (cross-talk from other PCB traces). Even if
>the wire was clamped to supply rail. Only workaround was to clip off the
>respective pin (PGA) since we didn't need it at all.
>
>People argued whether it was bad PCB design (no shielding of async
>signal) or bad chip design (no low-pass filter at async input). I'd say
>both :-)
>
>Arnim
>

A reset or any input may be left floating at a testing stage. I used a
cpld to configure FPGA and it will either fail or work on power up or upon
touching some board pins.
It turned out that the reset was floating being supposed to be driven from
a mother board which was not ready yet. The remedy was internal pull-up.

kadhiem

Article: 139739
Subject: Re: warning:impact:2217 error shows in the status register, CRC Error
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sat, 11 Apr 2009 06:20:45 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 9, 10:34=A0pm, jleslie48 <j...@jonathanleslie.com> wrote:
> Ok here's the story.
>
> I developed a message stream using a 32Mhz clock fpga putting out 64
> bits asynchronously using a dividing the clock by 8*2_000_000 (where
> 2_000_000 is the baud rate, I know that's very fast for a baud rate)
> to get the sample rate for the bits. =A0this resulted in a 2.00000
> perfect divisor for the sampling rate for the comm line.
>
> I switched to a 40Mhz clock fpga, and with keeping the 8 and 2_000_000
> numbers constant, my previous perfect divisor for the sampling rate
> now shifts to 40M/(8*2M) =3D=3D 2.5, and a bad drift occurs. =A0So I thin=
k
> no problem lets just use 10 samples per bit rather than 8 thus
> changing the formula to 40M/(10*2M) =3D=3D 2.000 and all will be fine
> again.
>
> And low and behold, Testbench confirms all is well. =A0 Now heres the
> problem, when I try and load this program onto the Spartan 3 chip, it
> dies. =A0with the above warning and the chip needs a power reset.
> Leaving the value of 10 in the sampling rate I can change the program
> from working to non working by playing with the following:
>
> -- Listing 7.3
>
> -- JL 090309 =A0 changing hard coded '15' to (sb_tick-1) for length of
> -- =A0 =A0 =A0 =A0 =A0 =A0 each bit. hard coded '7' for databits now (dbi=
t-1) as
> well.
> -- JL 090312 =A0 custom version of uart_tx for the 2mhz comm link.
>
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.numeric_std.all;
> entity uart40_tx is
> =A0 =A0generic(
> =A0 =A0 =A0 DBIT: integer:=3D64; =A0 =A0 -- # data bits
> =A0 =A0 =A0 SB_TICK: integer:=3D10 -- # ticks for each bit
> =A0 =A0);
> =A0 =A0port(
> =A0 =A0 =A0 clk,
> =A0 =A0 =A0 reset =A0 =A0 =A0: in std_logic;
> =A0 =A0 =A0 tx_start =A0 : in std_logic;
> =A0 =A0 =A0 s_tick =A0 =A0 : in std_logic;
> =A0 =A0 =A0 din =A0 =A0 =A0 =A0: in std_logic_vector((dbit-1) downto 0);
> =A0 =A0 =A0 =A0 =A0 tx_done_tick =A0: out std_logic;
> =A0 =A0 =A0 =A0 =A0 tx =A0 =A0 =A0 =A0 =A0 =A0: out std_logic
> =A0 =A0);
> end uart40_tx ;
>
> architecture arch of uart40_tx is
> =A0 =A0type state_type is (idle, start, data, stop);
>
> =A0 =A0constant go_high : std_logic :=3D '1';
> =A0 =A0constant go_low =A0: std_logic :=3D '0';
>
> =A0 =A0signal state_reg, state_next: state_type;
> =A0 =A0signal s_reg, s_next: unsigned(7 downto 0);
> =A0 =A0signal n_reg, n_next: unsigned(7 downto 0);
> =A0 =A0signal b_reg, b_next: std_logic_vector((dbit-1) downto 0);
> =A0 =A0signal tx_reg, tx_next: std_logic;
> =A0 =A0signal bit_length: std_logic :=3D '0'; =A0 =A0 -- testbench watchi=
ng
> only. =A0use with d
> begin
> =A0 =A0-- FSMD state & data registers
> =A0 =A0process(clk,reset)
> =A0 =A0begin
> =A0 =A0 =A0 if reset=3D'1' then
> =A0 =A0 =A0 =A0 =A0state_reg <=3D idle;
> =A0 =A0 =A0 =A0 =A0s_reg <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0n_reg <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0b_reg <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0tx_reg <=3D go_high;
> =A0 =A0 =A0 elsif (clk'event and clk=3D'1') then
> =A0 =A0 =A0 =A0 =A0state_reg <=3D state_next;
> =A0 =A0 =A0 =A0 =A0s_reg <=3D s_next;
> =A0 =A0 =A0 =A0 =A0n_reg <=3D n_next;
> =A0 =A0 =A0 =A0 =A0b_reg <=3D b_next;
> =A0 =A0 =A0 =A0 =A0tx_reg <=3D tx_next;
> =A0 =A0 =A0 end if;
> =A0 =A0end process;
> =A0 =A0-- next-state logic & data path functional units/routing
> =A0 =A0process(state_reg,s_reg,n_reg,b_reg,s_tick,
> =A0 =A0 =A0 =A0 =A0 =A0tx_reg,tx_start,din)
> =A0 =A0begin
> =A0 =A0 =A0 state_next <=3D state_reg;
> =A0 =A0 =A0 s_next <=3D s_reg;
> =A0 =A0 =A0 n_next <=3D n_reg;
> =A0 =A0 =A0 b_next <=3D b_reg;
> =A0 =A0 =A0 tx_next <=3D tx_reg ;
> =A0 =A0 =A0 tx_done_tick <=3D '0';
> =A0 =A0 =A0 case state_reg is
> =A0 =A0 =A0 =A0 =A0when idle =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D go_low;
> =A0 =A0 =A0 =A0 =A0 =A0 if tx_start=3D'1' then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state_next <=3D start;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0s_next <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_next <=3D din;
> =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 =A0when start =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D go_high;
> =A0 =A0 =A0 =A0 =A0 =A0 if (s_tick =3D '1') then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if s_reg=3D(sb_tick-1) then =A0 =A0 --(A)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state_next <=3D data;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 n_next <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D s_reg + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if;
> =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 =A0when data =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D b_reg(0);
> =A0 =A0 =A0 =A0 =A0 =A0 if (s_tick =3D '1') then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if s_reg=3D(sb_tick-1) then =A0 =A0 =A0 =
=A0 =A0 =A0--(A)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bit_length <=3D not bit_length; =A0--=
 measure a bit.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 b_next <=3D '0' & b_reg((dbit-1) down=
to 1) ;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if n_reg=3D(DBIT-1) then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state_next <=3D idle; -- stop =
; =A0 =A0--lets skip the
> stop bit.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tx_done_tick <=3D '1'; =A0 =A0=
 =A0 =A0 =A0 =A0 -- moved in from
> stop
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0n_next <=3D n_reg + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D s_reg + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if;
> =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 =A0when stop =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D go_high;
> =A0 =A0 =A0 =A0 =A0 =A0 if (s_tick =3D '1') then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if s_reg=3D(SB_TICK*4-1) then =A0 -- lets =
make it stick out
> for now.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state_next <=3D idle;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx_done_tick <=3D '1';
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D s_reg + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if;
> =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 end case;
> =A0 =A0end process;
> =A0 =A0tx <=3D tx_reg;
> end arch;
>
> -----------------------------------------------------------------
>
> Now the above has perfect results in the testbench, but crashes the
> fpga on a real load. =A0For a while I never got any message, but now I'm
> getting the
>
> warning:impact:2217 error shows in the status register, CRC Error Bit
> is NOT 0.
>
> as a pop-up window on the PC when I load the software via Impact.
>
> if I replace the two occurances of this line:
>
> (A) =A0 =A0 =A0 =A0 =A0 =A0 =A0 if s_reg=3D(sb_tick-1) then
>
> with this:
>
> (B) =A0 =A0 =A0 =A0 =A0 =A0 =A0 if s_reg=3D(sb_tick-2) then
>
> I no longer crash the fpga and all loads up fine and runs, albiet my
> message is no longer running at the
> right rate.
>
> I'm scratching my head as to what causes the error in the (A)
> situation that is not there in the (B) situation.
>
> Any insight greatly appreciated.
>
> Sincerely,
>
> Jonathan Leslie

IF small change in FPGA code causes the bitstream load CRC error to
"come and go", then:

1) bad and faulty FPGA - very unlikely
2) power supply issue VCCINT - more likely
3) xilinx tools generating bad bitfile - very unlikely

in theory, NO MATTER you write in the VHDL, it CAN NOT make the CRC
error during download to happen.

hm idea.. use USERCLOCK as startup clock

it may make the CRC error to go away or not

Antti









Article: 139740
Subject: Re: Getting efficient logic synthesis
From: Andy <jonesandy@comcast.net>
Date: Sat, 11 Apr 2009 06:51:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
This may sound silly, but did you try a simple 16:1 mux (albeit it
sounds like some of the choices would be the same value)? And did it
not meet timing, or were you just unhappy with the apparent
inefficiency? I've often had Synplify and other tools do a better job
with a simple description than with one in which I tried to hint to it
how I thought it could do better. Also, I usually had to use
constraints to keep it from burying/reorganizing signals when I wanted
to strongly hint a certain structure.

I have seen Synplify create some seemingly wasteful implentations in
an effort to improve performance for the placed and routed
implementation (i.e. considering likely routing delays from relative
locations of circuit elements). Keep in mind, by pushing back the
select line [datsel(2)] to the unused input of the LUT, you are
quadrupling its fanout (with associated delay), and increasing routing
congestion.

Andy

Article: 139741
Subject: Re: Noise in Stratix3?
From: Rob <nothear@nowhere.com>
Date: Sat, 11 Apr 2009 10:31:23 -0400
Links: << >>  << T >>  << A >>
Niv (KP) wrote:
> My stratix3 design simulates OK at RTL & gate-level.
> 
> On the PCB however, an internal module fails to read some M9K RAMS
> properly all the time
> when I connect an input signal to the chip, but which has nothing to
> do with the failing module.
> 
> Are there any crosstalk/noise issues with Strarix3 devices that anyone
> has encountered?
> 
> Basically, the s/w guys are testing the system and getting a lot of
> errors on reading this particular RAM,
> but removing this un-related signal (relative o the RAMs in question)
> reduces the error count a lot. (but not totally, apparently, possibly
> another signal also affecting?).
> 
> I have not floorplanned the design, but let Quartus do whatever it
> wanted routing wise to meet timing and pin-out.
> 
> Regards, Kev P.
A bit more information would be helpful.  What type of interface have 
you implemented that the software is using to read the internal RAMS?  I 
had a problem once where software claimed they were getting corrupt 
information but it turned out that they they were reading the ASIC 
(which interfaced to my FPGA) too fast, thus giving the appearance of 
corrupt registers.

Have you used the JTAG interface when you get into a software reported 
corruption issue.  There are some implementations of RAM that can be 
read (via JTAG) using the in-system memory editor.

Rob

Article: 139742
Subject: buy XSA-50
From: "Ged" <ciro.rossini@alice.it>
Date: Sat, 11 Apr 2009 16:46:58 +0200
Links: << >>  << T >>  << A >>
Hallo!
I'm Giuseppe an italian (informatic) engineering student. My professor uses 
a XSA-50 to make same interesting and amazing experiment. Is there someone 
that know where i can buy this board? Xess' site tells it isn't in stock. 
Can you help me? Thank you very much!

Best regards,
        Giuseppe 



Article: 139743
Subject: Re: warning:impact:2217 error shows in the status register, CRC Error
From: jleslie48 <jon@jonathanleslie.com>
Date: Sat, 11 Apr 2009 07:50:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 11, 9:20 am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Apr 9, 10:34 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
> > Ok here's the story.
>
> > I developed a message stream using a 32Mhz clock fpga putting out 64
> > bits asynchronously using a dividing the clock by 8*2_000_000 (where
> > 2_000_000 is the baud rate, I know that's very fast for a baud rate)
> > to get the sample rate for the bits.  this resulted in a 2.00000
> > perfect divisor for the sampling rate for the comm line.
>
> > I switched to a 40Mhz clock fpga, and with keeping the 8 and 2_000_000
> > numbers constant, my previous perfect divisor for the sampling rate
> > now shifts to 40M/(8*2M) == 2.5, and a bad drift occurs.  So I think
> > no problem lets just use 10 samples per bit rather than 8 thus
> > changing the formula to 40M/(10*2M) == 2.000 and all will be fine
> > again.
>
> > And low and behold, Testbench confirms all is well.   Now heres the
> > problem, when I try and load this program onto the Spartan 3 chip, it
> > dies.  with the above warning and the chip needs a power reset.
> > Leaving the value of 10 in the sampling rate I can change the program
> > from working to non working by playing with the following:
>
> > -- Listing 7.3
>
> > -- JL 090309   changing hard coded '15' to (sb_tick-1) for length of
> > --             each bit. hard coded '7' for databits now (dbit-1) as
> > well.
> > -- JL 090312   custom version of uart_tx for the 2mhz comm link.
>
> > library ieee;
> > use ieee.std_logic_1164.all;
> > use ieee.numeric_std.all;
> > entity uart40_tx is
> >    generic(
> >       DBIT: integer:=64;     -- # data bits
> >       SB_TICK: integer:=10 -- # ticks for each bit
> >    );
> >    port(
> >       clk,
> >       reset      : in std_logic;
> >       tx_start   : in std_logic;
> >       s_tick     : in std_logic;
> >       din        : in std_logic_vector((dbit-1) downto 0);
> >           tx_done_tick  : out std_logic;
> >           tx            : out std_logic
> >    );
> > end uart40_tx ;
>
> > architecture arch of uart40_tx is
> >    type state_type is (idle, start, data, stop);
>
> >    constant go_high : std_logic := '1';
> >    constant go_low  : std_logic := '0';
>
> >    signal state_reg, state_next: state_type;
> >    signal s_reg, s_next: unsigned(7 downto 0);
> >    signal n_reg, n_next: unsigned(7 downto 0);
> >    signal b_reg, b_next: std_logic_vector((dbit-1) downto 0);
> >    signal tx_reg, tx_next: std_logic;
> >    signal bit_length: std_logic := '0';     -- testbench watching
> > only.  use with d
> > begin
> >    -- FSMD state & data registers
> >    process(clk,reset)
> >    begin
> >       if reset='1' then
> >          state_reg <= idle;
> >          s_reg <= (others=>'0');
> >          n_reg <= (others=>'0');
> >          b_reg <= (others=>'0');
> >          tx_reg <= go_high;
> >       elsif (clk'event and clk='1') then
> >          state_reg <= state_next;
> >          s_reg <= s_next;
> >          n_reg <= n_next;
> >          b_reg <= b_next;
> >          tx_reg <= tx_next;
> >       end if;
> >    end process;
> >    -- next-state logic & data path functional units/routing
> >    process(state_reg,s_reg,n_reg,b_reg,s_tick,
> >            tx_reg,tx_start,din)
> >    begin
> >       state_next <= state_reg;
> >       s_next <= s_reg;
> >       n_next <= n_reg;
> >       b_next <= b_reg;
> >       tx_next <= tx_reg ;
> >       tx_done_tick <= '0';
> >       case state_reg is
> >          when idle =>
> >             tx_next <= go_low;
> >             if tx_start='1' then
> >                state_next <= start;
> >                s_next <= (others=>'0');
> >                b_next <= din;
> >             end if;
> >          when start =>
> >             tx_next <= go_high;
> >             if (s_tick = '1') then
> >                if s_reg=(sb_tick-1) then     --(A)
> >                   state_next <= data;
> >                   s_next <= (others=>'0');
> >                   n_next <= (others=>'0');
> >                else
> >                   s_next <= s_reg + 1;
> >                end if;
> >             end if;
> >          when data =>
> >             tx_next <= b_reg(0);
> >             if (s_tick = '1') then
> >                if s_reg=(sb_tick-1) then            --(A)
> >                   bit_length <= not bit_length;  -- measure a bit.
> >                   s_next <= (others=>'0');
> >                   b_next <= '0' & b_reg((dbit-1) downto 1) ;
> >                   if n_reg=(DBIT-1) then
> >                      state_next <= idle; -- stop ;    --lets skip the
> > stop bit.
> >                      tx_done_tick <= '1';             -- moved in from
> > stop
> >                   else
> >                      n_next <= n_reg + 1;
> >                   end if;
> >                else
> >                   s_next <= s_reg + 1;
> >                end if;
> >             end if;
> >          when stop =>
> >             tx_next <= go_high;
> >             if (s_tick = '1') then
> >                if s_reg=(SB_TICK*4-1) then   -- lets make it stick out
> > for now.
> >                   state_next <= idle;
> >                   tx_done_tick <= '1';
> >                else
> >                   s_next <= s_reg + 1;
> >                end if;
> >             end if;
> >       end case;
> >    end process;
> >    tx <= tx_reg;
> > end arch;
>
> > -----------------------------------------------------------------
>
> > Now the above has perfect results in the testbench, but crashes the
> > fpga on a real load.  For a while I never got any message, but now I'm
> > getting the
>
> > warning:impact:2217 error shows in the status register, CRC Error Bit
> > is NOT 0.
>
> > as a pop-up window on the PC when I load the software via Impact.
>
> > if I replace the two occurances of this line:
>
> > (A)               if s_reg=(sb_tick-1) then
>
> > with this:
>
> > (B)               if s_reg=(sb_tick-2) then
>
> > I no longer crash the fpga and all loads up fine and runs, albiet my
> > message is no longer running at the
> > right rate.
>
> > I'm scratching my head as to what causes the error in the (A)
> > situation that is not there in the (B) situation.
>
> > Any insight greatly appreciated.
>
> > Sincerely,
>
> > Jonathan Leslie
>
> IF small change in FPGA code causes the bitstream load CRC error to
> "come and go", then:
>
> 1) bad and faulty FPGA - very unlikely
> 2) power supply issue VCCINT - more likely
> 3) xilinx tools generating bad bitfile - very unlikely
>
> in theory, NO MATTER you write in the VHDL, it CAN NOT make the CRC
> error during download to happen.
>
> hm idea.. use USERCLOCK as startup clock
>
> it may make the CRC error to go away or not
>
> Antti

Its definitely in the vhdl code.  I change the VHDL code, and I change
the results.

very strange.   If this was a C program, I'd say this is similar to a
divide by zero execution.

I re-wrote the entire routine without the 8 or 10 looping iterations,
and I get the results I want so the crisis is over, but it still bugs
me that I can lock up my entire FPGA with code that I wrote.

I still have no idea why making the loop iterate 10 times vs 9 would
result in such catastrophic failure

I even tried leaving it looping 9 times, and then putting an interim
state to make the 9th iteration last for two clock cycles, it still
would not run.  That test changed my thinking to the 9,10 doesn't
directly cause the problem, but rather that driving the signal is
somehow messed up on the 10th cycle.  Again nothing unusual shows up
on the "behavior" test bench.  I don't know how to use the place and
route simulation, or whether or not modelsim will show the error.


Article: 139744
Subject: Re: warning:impact:2217 error shows in the status register, CRC Error
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Sat, 11 Apr 2009 07:57:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 11, 5:50=A0pm, jleslie48 <j...@jonathanleslie.com> wrote:
> On Apr 11, 9:20 am, "Antti.Luk...@googlemail.com"
>
>
>
> <Antti.Luk...@googlemail.com> wrote:
> > On Apr 9, 10:34 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
> > > Ok here's the story.
>
> > > I developed a message stream using a 32Mhz clock fpga putting out 64
> > > bits asynchronously using a dividing the clock by 8*2_000_000 (where
> > > 2_000_000 is the baud rate, I know that's very fast for a baud rate)
> > > to get the sample rate for the bits. =A0this resulted in a 2.00000
> > > perfect divisor for the sampling rate for the comm line.
>
> > > I switched to a 40Mhz clock fpga, and with keeping the 8 and 2_000_00=
0
> > > numbers constant, my previous perfect divisor for the sampling rate
> > > now shifts to 40M/(8*2M) =3D=3D 2.5, and a bad drift occurs. =A0So I =
think
> > > no problem lets just use 10 samples per bit rather than 8 thus
> > > changing the formula to 40M/(10*2M) =3D=3D 2.000 and all will be fine
> > > again.
>
> > > And low and behold, Testbench confirms all is well. =A0 Now heres the
> > > problem, when I try and load this program onto the Spartan 3 chip, it
> > > dies. =A0with the above warning and the chip needs a power reset.
> > > Leaving the value of 10 in the sampling rate I can change the program
> > > from working to non working by playing with the following:
>
> > > -- Listing 7.3
>
> > > -- JL 090309 =A0 changing hard coded '15' to (sb_tick-1) for length o=
f
> > > -- =A0 =A0 =A0 =A0 =A0 =A0 each bit. hard coded '7' for databits now =
(dbit-1) as
> > > well.
> > > -- JL 090312 =A0 custom version of uart_tx for the 2mhz comm link.
>
> > > library ieee;
> > > use ieee.std_logic_1164.all;
> > > use ieee.numeric_std.all;
> > > entity uart40_tx is
> > > =A0 =A0generic(
> > > =A0 =A0 =A0 DBIT: integer:=3D64; =A0 =A0 -- # data bits
> > > =A0 =A0 =A0 SB_TICK: integer:=3D10 -- # ticks for each bit
> > > =A0 =A0);
> > > =A0 =A0port(
> > > =A0 =A0 =A0 clk,
> > > =A0 =A0 =A0 reset =A0 =A0 =A0: in std_logic;
> > > =A0 =A0 =A0 tx_start =A0 : in std_logic;
> > > =A0 =A0 =A0 s_tick =A0 =A0 : in std_logic;
> > > =A0 =A0 =A0 din =A0 =A0 =A0 =A0: in std_logic_vector((dbit-1) downto =
0);
> > > =A0 =A0 =A0 =A0 =A0 tx_done_tick =A0: out std_logic;
> > > =A0 =A0 =A0 =A0 =A0 tx =A0 =A0 =A0 =A0 =A0 =A0: out std_logic
> > > =A0 =A0);
> > > end uart40_tx ;
>
> > > architecture arch of uart40_tx is
> > > =A0 =A0type state_type is (idle, start, data, stop);
>
> > > =A0 =A0constant go_high : std_logic :=3D '1';
> > > =A0 =A0constant go_low =A0: std_logic :=3D '0';
>
> > > =A0 =A0signal state_reg, state_next: state_type;
> > > =A0 =A0signal s_reg, s_next: unsigned(7 downto 0);
> > > =A0 =A0signal n_reg, n_next: unsigned(7 downto 0);
> > > =A0 =A0signal b_reg, b_next: std_logic_vector((dbit-1) downto 0);
> > > =A0 =A0signal tx_reg, tx_next: std_logic;
> > > =A0 =A0signal bit_length: std_logic :=3D '0'; =A0 =A0 -- testbench wa=
tching
> > > only. =A0use with d
> > > begin
> > > =A0 =A0-- FSMD state & data registers
> > > =A0 =A0process(clk,reset)
> > > =A0 =A0begin
> > > =A0 =A0 =A0 if reset=3D'1' then
> > > =A0 =A0 =A0 =A0 =A0state_reg <=3D idle;
> > > =A0 =A0 =A0 =A0 =A0s_reg <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0n_reg <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0b_reg <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0tx_reg <=3D go_high;
> > > =A0 =A0 =A0 elsif (clk'event and clk=3D'1') then
> > > =A0 =A0 =A0 =A0 =A0state_reg <=3D state_next;
> > > =A0 =A0 =A0 =A0 =A0s_reg <=3D s_next;
> > > =A0 =A0 =A0 =A0 =A0n_reg <=3D n_next;
> > > =A0 =A0 =A0 =A0 =A0b_reg <=3D b_next;
> > > =A0 =A0 =A0 =A0 =A0tx_reg <=3D tx_next;
> > > =A0 =A0 =A0 end if;
> > > =A0 =A0end process;
> > > =A0 =A0-- next-state logic & data path functional units/routing
> > > =A0 =A0process(state_reg,s_reg,n_reg,b_reg,s_tick,
> > > =A0 =A0 =A0 =A0 =A0 =A0tx_reg,tx_start,din)
> > > =A0 =A0begin
> > > =A0 =A0 =A0 state_next <=3D state_reg;
> > > =A0 =A0 =A0 s_next <=3D s_reg;
> > > =A0 =A0 =A0 n_next <=3D n_reg;
> > > =A0 =A0 =A0 b_next <=3D b_reg;
> > > =A0 =A0 =A0 tx_next <=3D tx_reg ;
> > > =A0 =A0 =A0 tx_done_tick <=3D '0';
> > > =A0 =A0 =A0 case state_reg is
> > > =A0 =A0 =A0 =A0 =A0when idle =3D>
> > > =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D go_low;
> > > =A0 =A0 =A0 =A0 =A0 =A0 if tx_start=3D'1' then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state_next <=3D start;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0s_next <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_next <=3D din;
> > > =A0 =A0 =A0 =A0 =A0 =A0 end if;
> > > =A0 =A0 =A0 =A0 =A0when start =3D>
> > > =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D go_high;
> > > =A0 =A0 =A0 =A0 =A0 =A0 if (s_tick =3D '1') then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if s_reg=3D(sb_tick-1) then =A0 =A0 --=
(A)
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state_next <=3D data;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 n_next <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D s_reg + 1;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if;
> > > =A0 =A0 =A0 =A0 =A0 =A0 end if;
> > > =A0 =A0 =A0 =A0 =A0when data =3D>
> > > =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D b_reg(0);
> > > =A0 =A0 =A0 =A0 =A0 =A0 if (s_tick =3D '1') then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if s_reg=3D(sb_tick-1) then =A0 =A0 =
=A0 =A0 =A0 =A0--(A)
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bit_length <=3D not bit_length; =
=A0-- measure a bit.
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 b_next <=3D '0' & b_reg((dbit-1) =
downto 1) ;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if n_reg=3D(DBIT-1) then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state_next <=3D idle; -- s=
top ; =A0 =A0--lets skip the
> > > stop bit.
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tx_done_tick <=3D '1'; =A0=
 =A0 =A0 =A0 =A0 =A0 -- moved in from
> > > stop
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0n_next <=3D n_reg + 1;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D s_reg + 1;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if;
> > > =A0 =A0 =A0 =A0 =A0 =A0 end if;
> > > =A0 =A0 =A0 =A0 =A0when stop =3D>
> > > =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D go_high;
> > > =A0 =A0 =A0 =A0 =A0 =A0 if (s_tick =3D '1') then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if s_reg=3D(SB_TICK*4-1) then =A0 -- l=
ets make it stick out
> > > for now.
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state_next <=3D idle;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx_done_tick <=3D '1';
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D s_reg + 1;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if;
> > > =A0 =A0 =A0 =A0 =A0 =A0 end if;
> > > =A0 =A0 =A0 end case;
> > > =A0 =A0end process;
> > > =A0 =A0tx <=3D tx_reg;
> > > end arch;
>
> > > -----------------------------------------------------------------
>
> > > Now the above has perfect results in the testbench, but crashes the
> > > fpga on a real load. =A0For a while I never got any message, but now =
I'm
> > > getting the
>
> > > warning:impact:2217 error shows in the status register, CRC Error Bit
> > > is NOT 0.
>
> > > as a pop-up window on the PC when I load the software via Impact.
>
> > > if I replace the two occurances of this line:
>
> > > (A) =A0 =A0 =A0 =A0 =A0 =A0 =A0 if s_reg=3D(sb_tick-1) then
>
> > > with this:
>
> > > (B) =A0 =A0 =A0 =A0 =A0 =A0 =A0 if s_reg=3D(sb_tick-2) then
>
> > > I no longer crash the fpga and all loads up fine and runs, albiet my
> > > message is no longer running at the
> > > right rate.
>
> > > I'm scratching my head as to what causes the error in the (A)
> > > situation that is not there in the (B) situation.
>
> > > Any insight greatly appreciated.
>
> > > Sincerely,
>
> > > Jonathan Leslie
>
> > IF small change in FPGA code causes the bitstream load CRC error to
> > "come and go", then:
>
> > 1) bad and faulty FPGA - very unlikely
> > 2) power supply issue VCCINT - more likely
> > 3) xilinx tools generating bad bitfile - very unlikely
>
> > in theory, NO MATTER you write in the VHDL, it CAN NOT make the CRC
> > error during download to happen.
>
> > hm idea.. use USERCLOCK as startup clock
>
> > it may make the CRC error to go away or not
>
> > Antti
>
> Its definitely in the vhdl code. =A0I change the VHDL code, and I change
> the results.
>
> very strange. =A0 If this was a C program, I'd say this is similar to a
> divide by zero execution.
>
> I re-wrote the entire routine without the 8 or 10 looping iterations,
> and I get the results I want so the crisis is over, but it still bugs
> me that I can lock up my entire FPGA with code that I wrote.
>
> I still have no idea why making the loop iterate 10 times vs 9 would
> result in such catastrophic failure
>
> I even tried leaving it looping 9 times, and then putting an interim
> state to make the 9th iteration last for two clock cycles, it still
> would not run. =A0That test changed my thinking to the 9,10 doesn't
> directly cause the problem, but rather that driving the signal is
> somehow messed up on the 10th cycle. =A0Again nothing unusual shows up
> on the "behavior" test bench. =A0I don't know how to use the place and
> route simulation, or whether or not modelsim will show the error.

nothing that ANY simulation could ever show can have any relevance
to the CRC error during configuration

Antti

Article: 139745
Subject: Re: Programming Digilent Nexys 2 from Linux
From: Andy Ross <andy.ross.or@gmail.com>
Date: Sat, 11 Apr 2009 08:34:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 10, 2:51=A0pm, John Eaton <nos...@spam.com> wrote:
> < bitgen ${PROJ}_par.ncd $PROJ.bit $PROJ.pcf
> ---
> =A0> bitgen $PROJ_par.ncd $PROJ.bit $PROJ.pcf

Good catch.  Fixed in the tarball (didn't bother with versioning).

FWIW: your diff order is swapped.  And, dude: non-unified diff output?
Raised in a barn?

Andy

Article: 139746
Subject: Re: warning:impact:2217 error shows in the status register, CRC Error
From: jleslie48 <jon@jonathanleslie.com>
Date: Sat, 11 Apr 2009 08:43:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 11, 10:57 am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Apr 11, 5:50 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
> > On Apr 11, 9:20 am, "Antti.Luk...@googlemail.com"
>
> > <Antti.Luk...@googlemail.com> wrote:
> > > On Apr 9, 10:34 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
> > > > Ok here's the story.
>
> > > > I developed a message stream using a 32Mhz clock fpga putting out 64
> > > > bits asynchronously using a dividing the clock by 8*2_000_000 (where
> > > > 2_000_000 is the baud rate, I know that's very fast for a baud rate)
> > > > to get the sample rate for the bits.  this resulted in a 2.00000
> > > > perfect divisor for the sampling rate for the comm line.
>
> > > > I switched to a 40Mhz clock fpga, and with keeping the 8 and 2_000_000
> > > > numbers constant, my previous perfect divisor for the sampling rate
> > > > now shifts to 40M/(8*2M) == 2.5, and a bad drift occurs.  So I think
> > > > no problem lets just use 10 samples per bit rather than 8 thus
> > > > changing the formula to 40M/(10*2M) == 2.000 and all will be fine
> > > > again.
>
> > > > And low and behold, Testbench confirms all is well.   Now heres the
> > > > problem, when I try and load this program onto the Spartan 3 chip, it
> > > > dies.  with the above warning and the chip needs a power reset.
> > > > Leaving the value of 10 in the sampling rate I can change the program
> > > > from working to non working by playing with the following:
>
> > > > -- Listing 7.3
>
> > > > -- JL 090309   changing hard coded '15' to (sb_tick-1) for length of
> > > > --             each bit. hard coded '7' for databits now (dbit-1) as
> > > > well.
> > > > -- JL 090312   custom version of uart_tx for the 2mhz comm link.
>
> > > > library ieee;
> > > > use ieee.std_logic_1164.all;
> > > > use ieee.numeric_std.all;
> > > > entity uart40_tx is
> > > >    generic(
> > > >       DBIT: integer:=64;     -- # data bits
> > > >       SB_TICK: integer:=10 -- # ticks for each bit
> > > >    );
> > > >    port(
> > > >       clk,
> > > >       reset      : in std_logic;
> > > >       tx_start   : in std_logic;
> > > >       s_tick     : in std_logic;
> > > >       din        : in std_logic_vector((dbit-1) downto 0);
> > > >           tx_done_tick  : out std_logic;
> > > >           tx            : out std_logic
> > > >    );
> > > > end uart40_tx ;
>
> > > > architecture arch of uart40_tx is
> > > >    type state_type is (idle, start, data, stop);
>
> > > >    constant go_high : std_logic := '1';
> > > >    constant go_low  : std_logic := '0';
>
> > > >    signal state_reg, state_next: state_type;
> > > >    signal s_reg, s_next: unsigned(7 downto 0);
> > > >    signal n_reg, n_next: unsigned(7 downto 0);
> > > >    signal b_reg, b_next: std_logic_vector((dbit-1) downto 0);
> > > >    signal tx_reg, tx_next: std_logic;
> > > >    signal bit_length: std_logic := '0';     -- testbench watching
> > > > only.  use with d
> > > > begin
> > > >    -- FSMD state & data registers
> > > >    process(clk,reset)
> > > >    begin
> > > >       if reset='1' then
> > > >          state_reg <= idle;
> > > >          s_reg <= (others=>'0');
> > > >          n_reg <= (others=>'0');
> > > >          b_reg <= (others=>'0');
> > > >          tx_reg <= go_high;
> > > >       elsif (clk'event and clk='1') then
> > > >          state_reg <= state_next;
> > > >          s_reg <= s_next;
> > > >          n_reg <= n_next;
> > > >          b_reg <= b_next;
> > > >          tx_reg <= tx_next;
> > > >       end if;
> > > >    end process;
> > > >    -- next-state logic & data path functional units/routing
> > > >    process(state_reg,s_reg,n_reg,b_reg,s_tick,
> > > >            tx_reg,tx_start,din)
> > > >    begin
> > > >       state_next <= state_reg;
> > > >       s_next <= s_reg;
> > > >       n_next <= n_reg;
> > > >       b_next <= b_reg;
> > > >       tx_next <= tx_reg ;
> > > >       tx_done_tick <= '0';
> > > >       case state_reg is
> > > >          when idle =>
> > > >             tx_next <= go_low;
> > > >             if tx_start='1' then
> > > >                state_next <= start;
> > > >                s_next <= (others=>'0');
> > > >                b_next <= din;
> > > >             end if;
> > > >          when start =>
> > > >             tx_next <= go_high;
> > > >             if (s_tick = '1') then
> > > >                if s_reg=(sb_tick-1) then     --(A)
> > > >                   state_next <= data;
> > > >                   s_next <= (others=>'0');
> > > >                   n_next <= (others=>'0');
> > > >                else
> > > >                   s_next <= s_reg + 1;
> > > >                end if;
> > > >             end if;
> > > >          when data =>
> > > >             tx_next <= b_reg(0);
> > > >             if (s_tick = '1') then
> > > >                if s_reg=(sb_tick-1) then            --(A)
> > > >                   bit_length <= not bit_length;  -- measure a bit.
> > > >                   s_next <= (others=>'0');
> > > >                   b_next <= '0' & b_reg((dbit-1) downto 1) ;
> > > >                   if n_reg=(DBIT-1) then
> > > >                      state_next <= idle; -- stop ;    --lets skip the
> > > > stop bit.
> > > >                      tx_done_tick <= '1';             -- moved in from
> > > > stop
> > > >                   else
> > > >                      n_next <= n_reg + 1;
> > > >                   end if;
> > > >                else
> > > >                   s_next <= s_reg + 1;
> > > >                end if;
> > > >             end if;
> > > >          when stop =>
> > > >             tx_next <= go_high;
> > > >             if (s_tick = '1') then
> > > >                if s_reg=(SB_TICK*4-1) then   -- lets make it stick out
> > > > for now.
> > > >                   state_next <= idle;
> > > >                   tx_done_tick <= '1';
> > > >                else
> > > >                   s_next <= s_reg + 1;
> > > >                end if;
> > > >             end if;
> > > >       end case;
> > > >    end process;
> > > >    tx <= tx_reg;
> > > > end arch;
>
> > > > -----------------------------------------------------------------
>
> > > > Now the above has perfect results in the testbench, but crashes the
> > > > fpga on a real load.  For a while I never got any message, but now I'm
> > > > getting the
>
> > > > warning:impact:2217 error shows in the status register, CRC Error Bit
> > > > is NOT 0.
>
> > > > as a pop-up window on the PC when I load the software via Impact.
>
> > > > if I replace the two occurances of this line:
>
> > > > (A)               if s_reg=(sb_tick-1) then
>
> > > > with this:
>
> > > > (B)               if s_reg=(sb_tick-2) then
>
> > > > I no longer crash the fpga and all loads up fine and runs, albiet my
> > > > message is no longer running at the
> > > > right rate.
>
> > > > I'm scratching my head as to what causes the error in the (A)
> > > > situation that is not there in the (B) situation.
>
> > > > Any insight greatly appreciated.
>
> > > > Sincerely,
>
> > > > Jonathan Leslie
>
> > > IF small change in FPGA code causes the bitstream load CRC error to
> > > "come and go", then:
>
> > > 1) bad and faulty FPGA - very unlikely
> > > 2) power supply issue VCCINT - more likely
> > > 3) xilinx tools generating bad bitfile - very unlikely
>
> > > in theory, NO MATTER you write in the VHDL, it CAN NOT make the CRC
> > > error during download to happen.
>
> > > hm idea.. use USERCLOCK as startup clock
>
> > > it may make the CRC error to go away or not
>
> > > Antti
>
> > Its definitely in the vhdl code.  I change the VHDL code, and I change
> > the results.
>
> > very strange.   If this was a C program, I'd say this is similar to a
> > divide by zero execution.
>
> > I re-wrote the entire routine without the 8 or 10 looping iterations,
> > and I get the results I want so the crisis is over, but it still bugs
> > me that I can lock up my entire FPGA with code that I wrote.
>
> > I still have no idea why making the loop iterate 10 times vs 9 would
> > result in such catastrophic failure
>
> > I even tried leaving it looping 9 times, and then putting an interim
> > state to make the 9th iteration last for two clock cycles, it still
> > would not run.  That test changed my thinking to the 9,10 doesn't
> > directly cause the problem, but rather that driving the signal is
> > somehow messed up on the 10th cycle.  Again nothing unusual shows up
> > on the "behavior" test bench.  I don't know how to use the place and
> > route simulation, or whether or not modelsim will show the error.
>
> nothing that ANY simulation could ever show can have any relevance
> to the CRC error during configuration
>
> Antti

when I first encountered the error, I didn't get a CRC error.  It
simply would load the program,
and then my heartbeat led would not blink, I got no response from any
of my other outputs,
and I could no longer communicate to the FPGA until I recycled power
on the board.


Article: 139747
Subject: Re: Avnet spartan 3A design issue
From: Muzaffer Kal <kal@dspia.com>
Date: Sat, 11 Apr 2009 10:18:00 -0700
Links: << >>  << T >>  << A >>
On Fri, 10 Apr 2009 13:44:50 -0700 (PDT), axr0284 <axr0284@yahoo.com>
wrote:

>Hi,
> I have been trying to understand the reason for the flash addressing
>scheme in the example design
>Avt3S400A_Eval_MB_parallel_flash_v10_1_01. The flash chip used is
>S29GL032N.
>
>
>1) It seems that the design is using a 2Mx16Bits flash. but the
>accessible address of the core is set to 4M in the xps address
>section. Is that suppose to be in bytes? I thought that the PLB bus
>supports 32 bits so shouldn't the address base be based on 32 bits.
>
The flash chip can be used in both byte mode and 16 bit word mode so
you need at least 4M words of address space to access it in both
modes. The schematic supports both modes too. So there is no 32 bit
mode from the flash.
>
>2) On top of that, it seems that the PLB 32 bit address is going
>through a bus splitter and then address bits 10 to 30 is sent to the
>flash core. Can anybody explain why that is the case?

The schematic has 22 bits of address connected to the flash. You need
to figure out where the other bit is coming from by looking at the
design.

>
>3) The address setup is 0x84c00000 to 84FFFFFF. Does that mean if I
>write to address 0x84C00000, it will be mapped to address 0 and
>0x84C00002 will be sent to address 1 on the Flash.
>

To understand how this is done, you need to trace how the address is
mapped to the FPGA pins. Flash address pin A1 is connected to N16 pin
of the FPGA, so the word at flash address 0 gets mapped accordingly.
You need to trace all the pins and understand where the address space
of flash gets mapped to.
The following document should help you:

http://www.files.em.avnet.com/files/177/xlx_s3a_evl_ug_rev2_112008.pdf
-- 
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com

Article: 139748
Subject: Decimation clock
From: fpgaasicdesigner@gmail.com
Date: Sat, 11 Apr 2009 12:30:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

If I have to decimate by 10.

Is it better to create a second clock2=1/10 clock1 from a counter
or
in the second stage working at clock2, make work this part on clock1
in multi-cycle

always@(posedge clock1)
if (reset)
...
else
if (count=9)
   design to work at clk2
end
end

or

always @posedge clock2
if (reset)
...
else
design working at clk2
end

I guess it is safety to use all on clock1 domain, easier for the
synthesis tool...
We don't have to take care of te delay between clock1 and clock2
generated with clock1

Thanks

Article: 139749
Subject: Re: Decimation clock
From: rickman <gnuarm@gmail.com>
Date: Sat, 11 Apr 2009 12:36:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 11, 3:30=A0pm, fpgaasicdesig...@gmail.com wrote:
> Hi,
>
> If I have to decimate by 10.
>
> Is it better to create a second clock2=3D1/10 clock1 from a counter
> or
> in the second stage working at clock2, make work this part on clock1
> in multi-cycle
>
> always@(posedge clock1)
> if (reset)
> ...
> else
> if (count=3D9)
> =A0 =A0design to work at clk2
> end
> end
>
> or
>
> always @posedge clock2
> if (reset)
> ...
> else
> design working at clk2
> end
>
> I guess it is safety to use all on clock1 domain, easier for the
> synthesis tool...
> We don't have to take care of te delay between clock1 and clock2
> generated with clock1
>
> Thanks

That is exactly right, although the tool doesn't care about the
phasing of your clocks.  It will be up to you to deal with any issues
of crossing clock domains.  So you are always better off using an
enable rather than a second clock if possible.

Rick



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search