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
On Apr 9, 9:04=A0am, "Symon" <symon_bre...@hotmail.com> wrote: > "rickman" <gnu...@gmail.com> wrote in message > > news:422e8790-d992-4a8a-b51a-871688f231ca@v28g2000vbb.googlegroups.com... > > > =A0 I > > have not used any of the cores there, but I spent a fair amount of > > time researching the available CPU designs. > > > Rick > > In the spirit of FOSS, would you share the results of your research? Mayb= e > offer it to the opencores website to help others. > Thanks, Symon. I didn't compile anything, so there is nothing written to offer. Mainly I was looking for a small core that would be useful in an FPGA for offloading control and other functions that did not need to run at the full speed the FPGA is capable of. I found just a very few that were at all like I needed and I don't think any of them were especially optmised for code size or even for gates. Most of the cores that were fully developed with good software support were the larger RISC type cores using 2000 LUTs or more (much like the microBlaze). If I had anything to offer in this regard, I would be happy to put a little time into plumping it up to post. The real problem I found was that much of the info I would like to see on each core was just plain missing. Some of them literally had ***NO*** documentation whatsoever. I don't know why anyone would bother to post a CPU design if they weren't even willing to write some basic description of what the thing is, how it works and how it is different from the other 99 cores on the web site. In the meantime I have worked on my own design and will be writing code for it shortly. I have not decided if I will be posting it or not, but either way it will be documented as I am building it in order to use in commercial designs. The documentation is as much for myself as anyone. I find if I have to maintain something, I need documentation so that I can figure it out again. RickArticle: 139701
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
Article: 139702
Dave Farrance wrote:
> Adding a second d-type with a short propagation delay from the first
> means that there's a whole clock cycle for the first stage to come out of
> metastability and give a good setup time for the second D-type, so that
> *its* Q output is either a secure 0 or 1 but not something between the
> two.
I think of the second flop as an analog gain stage.
"The decider"
-- Mike Treseler
Article: 139703Hello, I am using a xilinx spartan 3 for a processor design, and in my pipeline i need to write register file on falling edge and read on rising edge ... I need to do this for 2 ports at a time .. i am using built-in block ram for the reg file, but i cannot seem to get it to respond on each edge ... my solution is to divide the clock only for the reg file, but this is a kludge .. does someone know how I can do this? Thank you. ...Article: 139704
Hi,
I cannot understand the Nearest Even mode of Xilinx CORDIC core, see
below. In specific, I don't know its rule about the quantization.
Could you explain it to me?
From the example, it is different from that of Matlab fixed point
toolbox definition. I really don't understand the phrase: (1/2 rounded
down and 3/2 is rounded up).
BTW, I cannot find any simple example or routine to do the
quantization test and evaluation in Xilinx tool.
Thanks.
Round Mode
The CORDIC core provides four rounding modes:
=95 Truncate: The X_OUT, Y_OUT, and PHASE_OUT outputs are truncated.
=95 Positive Infinity: The X_OUT, Y_OUT, and PHASE_OUT outputs are
rounded (1/2 rounded up).
=95 Pos Neg Infinity: The outputs X_OUT, Y_OUT, and PHASE_OUT are
rounded (1/2 rounded up,
-1/2 rounded down).
Nearest Even: The X_OUT, Y_OUT, and PHASE_OUT outputs are rounded
toward the nearest
even number (1/2 rounded down and 3/2 is rounded up).
Table 8: Rounding Modes
Truncate Round+/- Round
+ Even
1.50 1
2 2 2
1.00 1
1 1 1
0.50 0
1 1 0
0.25 0
0 0 0
0.00 0
0 0 0
- 0.25 -1
0 0 0
- 0.50 -1
-1 0 -1
- 0.75 -1
-1 -1 -1
Article: 139705fl <rxjwg98@gmail.com> wrote: > I cannot understand the Nearest Even mode of Xilinx CORDIC core, see > below. In specific, I don't know its rule about the quantization. > Could you explain it to me? I don't know specifically about Xilinx, but round to even is popular in statistics to avoid the bias that you would otherwise get in rounding. > From the example, it is different from that of Matlab fixed point > toolbox definition. I really don't understand the phrase: (1/2 rounded > down and 3/2 is rounded up). > BTW, I cannot find any simple example or routine to do the > quantization test and evaluation in Xilinx tool. If you are rounding to the nearest integer, and the value is half way between two integers, you round to the one that is even. That is, 0.5 rounds down to 0, 1.5 up to 2. Business people might prefer rounding up. I know tax people like rounding up as it generates more tax revenue. -- glenArticle: 139706
On Apr 9, 1:06=A0pm, EDPHWSW <ed.pat...@gmail.com> wrote: > Hello, > > I am using a xilinx spartan 3 for a processor design, and in my > pipeline i need to write register file on falling edge and read on > rising edge ... I need to do this for 2 ports at a time .. =A0i am using > built-in block ram for the reg file, but i cannot seem to get it to > respond on each edge ... my solution is to divide the clock only for > the reg file, but this is a kludge .. does someone know how I can do > this? > > Thank you. ... Do you know that every write operation automatically also reads the data in the write-addressed location, and you have a choice to either read the "old" =3D previous information, or the "new" information that you are just writing ? The first option is the more valuable one. This feature might make your dual-edge operation unnecessary. Peter Alfke, XilinxArticle: 139707
Yes true, There is an option for Chipscope definition and implementation file. But it simply add .CDC file. When I click this file in Project navigator, it opens Chipscope Inserter after synthesizing the design. It asks to define ICON block then adds ILA blocks for that particular ICON block ONLY. This is quite inconvenient method It has generated many signals/wires after synthesis. I need to connect each signal to ILA. Also, the chipscope files are only used with respective project. I personally never prefer Project Nagivator for design entry but now I am forced to use only that software. Therefore, I am finding any possibility to insert .edn file before synthesis. On Apr 9, 10:42=A0pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > If I recall correctly you should be able to just go to New on the ISE men= u > and add a chipscope block. You can then just configure it to add the > signals that you need. > > Jon > > >Dear all, > > >1. I want to insert Chipscope blocks (ICON, ILA) into my design in > >Xilinx project navigator. > >2. I generated blocks from Chipscope Core Generator (.edn, .vhd, .ncf) > >but I do not know how I can assign .edn file into project navigator. > >3. I always used Mentor Graphics HDL Designer for design entry and it > >was very easy in that. I also know how to use signal tap (for Altera) > >but never used Chipscope directly with Project Navigator. > > >request for the some suggestions. > >Thanks > >MukeshArticle: 139708
On Apr 9, 5:18=A0pm, fl <rxjw...@gmail.com> wrote:
> Hi,
> I cannot understand the Nearest Even mode of Xilinx CORDIC core, see
> below. In specific, I don't know its rule about the quantization.
> Could you explain it to me?
> From the example, it is different from that of Matlab fixed point
> toolbox definition. I really don't understand the phrase: (1/2 rounded
> down and 3/2 is rounded up).
> BTW, I cannot find any simple example or routine to do the
> quantization test and evaluation in Xilinx tool.
>
> Thanks.
>
> Round Mode
> The CORDIC core provides four rounding modes:
> =95 Truncate: The X_OUT, Y_OUT, and PHASE_OUT outputs are truncated.
> =95 Positive Infinity: The X_OUT, Y_OUT, and PHASE_OUT outputs are
> rounded (1/2 rounded up).
> =95 Pos Neg Infinity: The outputs X_OUT, Y_OUT, and PHASE_OUT are
> rounded (1/2 rounded up,
> -1/2 rounded down).
> Nearest Even: The X_OUT, Y_OUT, and PHASE_OUT outputs are rounded
> toward the nearest
> even number (1/2 rounded down and 3/2 is rounded up).
>
> Table 8: Rounding Modes
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Truncate =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Ro=
und+/- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Round
> + =A0 =A0 =A0 =A0 =A0Even
> 1.50 =A0 =A0 =A0 =A0 1
> 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A02
> 1.00 =A0 =A0 =A0 =A0 1
> 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A01
> 0.50 =A0 =A0 =A0 =A0 0
> 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A00
> 0.25 =A0 =A0 =A0 =A0 0
> 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A00
> 0.00 =A0 =A0 =A0 =A0 0
> 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A00
> - 0.25 =A0 =A0 =A0-1
> 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A00
> - 0.50 =A0 =A0 =A0-1
> -1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 -1
> - 0.75 =A0 =A0 =A0-1
> -1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-1 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 -1
Table 8: Rounding Modes
Truncate Round+/- Round
+ Even
1.50 1
2 2 2
1.00 1
1 1 1
0.50 0
1 1 0
0.25 0
0 0 0
0.00 0
0 0 0
- 0.25 -1
0 0 0
- 0.50 -1
-1 0 -1
- 0.75 -1 -1
-1 -1
Why the quantization of -0.5 is -1 for Even? Thanks
Article: 139709My 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.Article: 139710
Thank you Jon.Article: 139711
Hi, 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...Article: 139712
On Fri, 10 Apr 2009 02:00:15 -0700 (PDT), "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? I hate to say this, but it's *much* more likely to be a synchronization issue than crosstalk/noise - this external input, is it propertly resynch'd before being used in your FPGA? I know you are a very experienced designer, so I suspect you already thought of that. But just in case... it *is* by far the most common reason, in my experience, for such random weirdnesses. regards -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 139713
On Fri, 10 Apr 2009 05:49:23 -0700 (PDT), "Naveen........." <kumarg.naveen@gmail.com> wrote: >Hi, >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... -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 139714
On Apr 10, 5:04=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Fri, 10 Apr 2009 02:00:15 -0700 (PDT), "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? > > I hate to say this, but it's *much* more likely to be a > synchronization issue than crosstalk/noise - this external input, > is it propertly resynch'd before being used in your FPGA? > > I know you are a very experienced designer, so I suspect > you already thought of that. =A0But just in case... =A0it *is* > by far the most common reason, in my experience, for such > random weirdnesses. > > regards > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Jonathan OPs issue is not happening on the path where the signal is applied that causes RAM corruption. So, if the part of logic that reads the RAM works, then it should work, not matter the unrelated signal. And if whatever problems are on the path of that unrelated to RAM signal, may cause problems, but those should not make the RAM corrupted. but yes, it is very much likely that there is some hidden dependancy from the signal thats seems unrelated. as of cross-talk inside FPGA.. maybe, just maybe i have once seen it. but i was experimenting with actual fabric max speed measurements, and was trying to feed 1GHz signals accross V-4 chip. and even then, i am not sure what it was, as the signal speed was at max fabric speeds i succeeded to actually measure 975MHz signals inside V4 (slowest speed grade) but those signal do not travel very far so, the real cross talk, can not be 100% excluded, but it is VERY VERY unlikely, but differences in routing can cause things to be very different, and that may cause the unrelated part to fail if enabling external signal (unrelated to the RAM) caused ram failures, while using 100% same bitstrream (that is the unrelated signal path exists) then well if the unrelated signals is say 250 mhz external clock that controls most of the FPGA, then it could cause problems because of power supply if VCCINT is out of spec has noise, then real weird things can happen. spartan-3 can report JTAG ID of Virtex-4 faulty FPGA is sometimes also possible, the unrelated signal may put change the placement to avoid damaged part but, this is also very unlikely seen only once a partially dead FPGA, Xilinx spartan3E, after power supply IC burned, replaced IC, but FPGA was only partially working .. and as usual, issue between ears.. sleep over it, try again make the test case simpler, try to remove all that isnt relevant and retest. once I called a fellow engineer to monitor what i was doing, to document an issue that was by all means something that shouldnt be possible. try lock the failing RAM to different locations, and try those change at random some optimization setting, and try all not very funny solution, i know AnttiArticle: 139715
On Apr 10, 2:00=A0am, "Niv (KP)" <kev.pars...@mbda-systems.com> 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. This type of problem can be very frustrating to solve. Given the strange interaction you observe between supposedly unrelated signal & ram, I'd look into the following things: a) are all the power supplies to the part clean & solid? Good ground plane under the FPGA? b) did the design met all the timing constraints? c) is there a "bus fight" between external signals and FPGA output signals? d) are there any floating inputs that could be drifting into the no- mans land of neither on nor off? e) are the input clocks all high quality? Good luck - let us know what you find. John ProvidenzaArticle: 139716
Xilinx S3A starterkit 8 LEDs are programmed to display some debug value rocker switch is used as system reset input FPGA design set LED to constant value, all I/O are output only that control LEDs 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!! ah, let it be mini Quiz: 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) AnttiArticle: 139717
"Niv (KP)" <kev.parsons@mbda-systems.com> wrote in message news:fd286f17-b434-4b03-aa38-f77e6f69f608@v28g2000vbb.googlegroups.com... > 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. Niv - having been using Stratix 3's for the past 2 years, and recently started using Stratix 4's on some complex Image processing and communications functions that are heavily internal RAM dependent, I cannot say I have ever come across this problem. As you are not floor planning the design - and I assume you have not also back annotated proven modules, then I suspect that you DO have a timing problem. Removing the unrelated signal in an unconstrained design merely gives the router more options to screw your layout on the next compile. I suggest that at the very least you logic-lock your RAM/RAM control module in to a minimal area to constrain the routing options - and when you verified all the routing delays are not a problem in that module - LOCK IT! But then what do I know - I design using schematics LOL! DaveArticle: 139718
On Apr 10, 11:38=A0am, "Dave Wilson" <d...@noaddress.net> wrote: > "Niv (KP)" <kev.pars...@mbda-systems.com> wrote in message > > news:fd286f17-b434-4b03-aa38-f77e6f69f608@v28g2000vbb.googlegroups.com... > > > > > > > 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. > > Niv - having been using Stratix 3's for the past 2 years, and recently > started using Stratix 4's on some complex Image processing and > communications functions that are heavily internal RAM dependent, I canno= t > say I have ever come across this problem. > > As you are not floor planning the design - and I assume you have not also > back annotated proven modules, then I suspect that you DO have a timing > problem. Removing the unrelated signal in an unconstrained design merely > gives the router more options to screw your layout on the next compile. > > I suggest that at the very least you logic-lock your RAM/RAM control modu= le > in to a minimal area to constrain the routing options - and when you > verified all the routing delays are not a problem in that module - LOCK I= T! > > But then what do I know - I design using schematics LOL! > > Dave- Hide quoted text - > > - Show quoted text - If I understand the OP correctly, the FPGA design/placement/routing is not changing, but the FPGA behavior is changing based on whether this unrelated, external signal is connected to the IC or not. I would look closely at that signal. Is it properly referenced to the local ground for the FPGA? Does it violate any input signal specs (abs min/max voltage, vinH/ vinL, rise/fall time, min pulse width, etc.)? Is the signal active before/during when the FPGA is powering up and/ or configuring? Is the signal synchronized properly? I suppose a massively parallel synchronized input could cause excess power draw during metastable conditions. Some of these issues can cause power problems on the FPGA die that can lead to wierd behavior in seemingly unrelated parts of the chip. If you have a relatively static spare output on the same bank (powered from the same bank supply), you could watch it and make sure it does not droop and/or spike. AndyArticle: 139719
"Andy" <jonesandy@comcast.net> wrote in message news:012ccb0d-615b-4443-9a58-093f73daedce@z1g2000yqn.googlegroups.com... On Apr 10, 11:38 am, "Dave Wilson" <d...@noaddress.net> wrote: > "Niv (KP)" <kev.pars...@mbda-systems.com> wrote in message > > news:fd286f17-b434-4b03-aa38-f77e6f69f608@v28g2000vbb.googlegroups.com... > > > > > > > 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. > > Niv - having been using Stratix 3's for the past 2 years, and recently > started using Stratix 4's on some complex Image processing and > communications functions that are heavily internal RAM dependent, I cannot > say I have ever come across this problem. > > As you are not floor planning the design - and I assume you have not also > back annotated proven modules, then I suspect that you DO have a timing > problem. Removing the unrelated signal in an unconstrained design merely > gives the router more options to screw your layout on the next compile. > > I suggest that at the very least you logic-lock your RAM/RAM control > module > in to a minimal area to constrain the routing options - and when you > verified all the routing delays are not a problem in that module - LOCK > IT! > > But then what do I know - I design using schematics LOL! > > Dave- Hide quoted text - > > - Show quoted text - >>f I understand the OP correctly, the FPGA design/placement/routing is >>not changing, but the FPGA behavior is changing based on whether this >>unrelated, external signal is connected to the IC or not. I would look >>closely at that signal. The OP actually stated "I have not floorplanned the design, but let Quartus do whatever it wanted routing wise to meet timing and pin-out." which implies (to me) a new roll of the dice each compile ..... But then what do I know - I design using schematics LOL! DaveArticle: 139720
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 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)Article: 139721
There are basically two ways to use Chipscope, via core generator and via core inserter. Core inserter is the way I prefer which uses the gui to assign the pins you want to probe. I do this initially and save the cdc. I later simply run everything in batch mode including the core insertion. Sound like you are doing the core gen method. In that case look at the icon and ila vhd files as instantiation templates and instantiate the cores in your source. Under the translate options specify where the edn files reside and you should be good to go.Article: 139722
On Apr 10, 8: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) security 101 data bit re-order : security =3D 0 xor with const: security =3D 0 xor with fixed lenght constant string: security =3D 0 xor data with address bits: security =3D 0 ... most of the systems are cloned because the designers just dont include any security AnttiArticle: 139723
On Apr 10, 7: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) I forgot to mention that the FPGA only sends/receives DATA block to/from FLASH, and that the controlling of the FLASH (sending command and address) is done by another micro. (not main CPU). The problem is internal to FPGA and has nothing to do with FLASH. (the flash sends back data in the order it has received it.) I just don't see why is the order of DBUS connections different in these two cases..Article: 139724
On Apr 8, 9:33=A0am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > You need to ensure that your output signals have the required setup time > relative to your output clock. What I usually do is to clock these signal= s > using the clk90 output of the DCM. That way you should easily meet the > setup time. > > Jon To get even tighter timing between outputs, you should ensure that all output registers are pushed into the IOB's. This gives very low skew between outputs switching on the same clock. Then using the quadrature clock gives you data centered around the clock edge for DDR designs.
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