Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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. RickArticle: 139726
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, GaborArticle: 139727
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
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 ideaArticle: 139729
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, AmishArticle: 139730
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"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. -MartyArticle: 139732
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. RickArticle: 139733
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: 139734On 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, > AmishArticle: 139735
> 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. ArnimArticle: 139736
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 AnttiArticle: 139737
>> 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 :-) ArnimArticle: 139738
> >>> 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. kadhiemArticle: 139739
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 AnttiArticle: 139740
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. AndyArticle: 139741
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. RobArticle: 139742
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: 139743On 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
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 AnttiArticle: 139745
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: 139746On 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
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.comArticle: 139748
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 ThanksArticle: 139749
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:
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