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 19/09/2012 15:38, jonesandy@comcast.net wrote: > On Tuesday, September 18, 2012 9:02:29 PM UTC-5, jt_eaton wrote: >> If you do that then you will never run an asynchronous reset signal down to the core flops. Read Xilinx WP-231. > > I've read WP-231, and it best be taken with a big dose of salt, like most generalizations. Please note the date, and the applicable series of FPGAs. > > If we are trying to avoid religion, "never" is a very long time and is almost certainly untrue. > > There are many valid reasons to use an asynchronous reset, and many valid reasons to use a synchronous reset. Right! http://microelectronics.esa.int/asic/fpga_001_01-0-2.pdf Skip to section 3.1. In a nutshell, the Nasa Wire satellite was lost due to the use of a synchronous reset. Hans www.ht-lab.com > Let's just leave it at that, without all the pontifications invoking "never" (or "always"). > > Besides, the OP's Q has nothing to do with async vs sync reset; both usually need to meet timing anyway. > > Andy >Article: 154276
In article <47cbefa7-3c40-4131-974e-0a1a09b61d3f@googlegroups.com>,
Carl <carwer0@gmail.com> wrote:
>An article on the local/global and synchronous/asynchronous aspects of resets:
>
>http://www.fpga-dev.com/resets-make-them-synchronous-and-local/
Okay, long post - this should probably go somewhere else, but here's
my reponse - it's some ideas that I've often thought of when seeing this
advice like this, but never get "pen to paper" as it were.
Thinking about resets are good, and having a good strategy,
very important, but I disagree with a lot of this advice.
And this type of advice been coming out of the FPGA companies for
a while.
But here's my 4 cents. (Too long for just 2 cents.)
I come from an ASIC background - where logic's cheap. ( I know this
is an FPGA newsgroup - bare with me. )
There, for all of our designs we used a global resets streategy, which
ASYNCHRONOUSLY reset FFs.
i.e. in verilog:
Example 1.
reg foo;
always @( posedge clk or negedge reset_n )
if( ~reset_n )
foo <= 0;
else
foo <= bar;
The reset_n input to the module was generated near the
top level of the chip. At the top level, the main system
reset would have it's de-assertion edge synchronized to each
clock domain - effectively creating a per-clock reset
signal. (I'm leaving out a LOT of qualifiers for this
including control of reset during test, etc. But the
key, the resets are generated at the top-level globally).
Furthermore, we reset EVERTHING that could be reset.
The requirements for the reset to work:
1. The input reset needs to be appropriately de-glitched
to avoid false assertions or de-assertions.
2. It's pulse width large enough to be capture by
the async input (on the order of nanoseconds)
That's it. You meet the above requirements, you'll safely enter the
reset state. You'll succesfully exit the reset state - once the reset
de-asserts AND THE CLOCK is running. If the clocks not running, you'll
stay reset.
The advantage of this approach:
Point 1. - You're always right. You can't hurt anything be resetting
a FF.
Point 2. - Simulating bringup is faster - perhaps MUCH faster. I've
spent sometimes weeks chasing the "sea-of-red" bring ups in
simulation - the results of X-Pessimism. I've seen all sorts of
kludge "demeta" tricks in simulation to work around these issue - and
there just that - Kludge testbench work that usually offers nothing
towards to the reliability of the design.
Point 3. - Reducing X's in simulation (by resetting everything) also
reduces the chances of X-Optimism. A much lower occuring problem,
but one with a larger penalty if missed (RTL sim vs. gates
mismatch).
The disadvantages - it's not optimal. You may waste resources
distributing the resets, and meeting the timing of the
reset recovery path. Note that all modern STA tools have
no trouble checking this timing.
Ask any business manager if this is the correct priority:
1. Correct, and Reliable.
2. Faster debug and verification.
3. Optimal
You won't get much argument. And that 3rd objective will probably be
MUCH lower that the first two.
The amount of logic "wasted" on this strategy, is tiny in this deep
sub-micron age. We even used the same clock tree methodology for
distributing the resets. Wasteful - sure. But who cares?
After a while of that I came over to FPGAs. FPGA's haven't been
designed to waste a global low-skew route on this async reset.
So, I switched to using synchronous resets:
Example 2.
reg foo;
always @( posedge clk )
if( ~reset_n )
foo <= 0;
else
foo <= bar;
Again the reset is generated globally, with de-assertion edge
synchronized to respective clock.
The requirements for reset to work : same as above PLUS:
3. You're clock must be running to enter reset.
A normally simple-to-meet requirement, but can lead to perplexing debug
in areas around non-free running clocks (i.e. around PLLs, and other
clock-management logic).
Again, I reset EVERYTHING that can be reset.
This strategy is not too different that the first. Some extra
head-scratching to be sure we're okay with extra reset requirement.
But in general it works.
The advantages and disadvantages of this approach are similar to the
first case. The back end tools must meet timing on all reset
paths. All FPGA tools will check this - the reset's basically just
like any other signal, albeit usually with a larger fanout.
To alleviate the large fanout - if it's even a problem, I can just
pipeline it (at the top level - globally!) a few times. Then allow
the tool to do any neccesary register duplication and perhaps register
balancing. The back end tools have solved this problem for me.
This leads my next evolution in resets: "Selective" reseting.
As many designers are apt to point out, EVERYTHING does not need
to be reset. This is true. Datapath logic is probably safe to leave
un-initialized.
Example 3.
reg [ 7 : 0 ] foo_data;
reg foo_control;
always @( posedge clk )
if( ~reset_n )
begin
foo_control <= 0;
//foo_data <= 0;
end
else
begin
foo_control <= bar;
foo_data <= some_data;
end
Here the control signal "foo_control" is reset. The datapath element
"foo_data" is not. And I usually code it just as above with the
reset clause explicity commented out.
The advantage of this approach - we can pick up a lot of optimizations
over reseting everything. Especially in targetting delay shift
registers (i.e. SRL16s in Xilinx).
But the disadvantages - slower coding, and the risk of missing a needed
reset. When I'm coding a low-level module - possible one that's going
to be shared across many FPGAs- I need to stop and think a bit more on
what must be reset, and what's safe to leave uninitialized. Do I know
of all use cases of this module? Will it be safe in all cases to not
reset this signal? This is often a hard requirement to decide. You
aften don't have all the information at the time of the coding to
make this decision.
So often I punt and leave the reset in - especially when
I bringup first testbenches and see that dreaded "sea-of-red".
If I suspect its got ANYTHING to do with that uninitialized signal -
that reset's going back in. I can always go back in and re-comment
out the reset assignement, to be more optimal.
But once the design is right how often will a designer be given the
time to go back in and make it more "optimal"? Probably only when
pushed into a corner.
The last style, often touted by FPGA companies, basically boils down
to - don't reset at all. The design comes up out of FPGA configuration
in a known, default state. Often the synthesis tools can be configured
to adjust this default state with init values:
Example 4.
reg [ 7 : 0 ] foo_data = 0;
reg foo_control = 0;
always @( posedge clk )
begin
foo_control <= bar;
foo_data <= some_data;
end
I.e. the synthesis tool uses the verilog init value as the configuration
time value. Here, reset's are the exception not the rule. Only reset
those very few elements that explicitly require it, and must see that
edge.
Advantages of this : an optimal design.
The biggest drawback... FPGA Configuration is usaully NOT equal to
RESET. Most of my boards have at least some kind of push-button reset,
probably another controlled by some sort of processor. This reset is
a distinct operation - quite seperate from FPGA "CONFIG".
Plus, well, I'm very hesitant with this approach. Reset and
initialization problems can lie hidden for a long time. During bringup,
often a lot of things are in flux, and a random init problem is often
written off as some random event, and ignored. "Hey I just ran it
again it worked this time."
So the problem lies hidden much longer. Months down the line when
my manufacturing line ( or worse - customer ) comes back to be and
says, "Hey I sometimes have to reset this thing twice to get it to
work". I'd be MUCH more comfortable in this situation knowing that
I had a solid reset in my FPGA design.
"Correct and Reliable" has priority over "Optimal" for me.
Regards,
Mark
Article: 154277
Mark,
Nice write-up! In the end, if you count up all the time (money) spent deter=
mining AND VERIFYING what does not NEED to be reset, you'd have been better=
off resetting everything to start with, and only pulling out the reset whe=
re it kills your utilization (by kill, I don't mean raises util from 85% to=
86%, I mean it doesn't fit!).=20
The pipe-lining/retiming trick for handling fanout on the synchronous reset=
also works great for synchronously deasserted asynchronous resets!
When coding a process that has some registers reset and others not, if you =
use the familiar "reset ... elsif clock ..." structure, your fanout on rese=
t may not be reduced, because every register that saved a reset, added a cl=
ock enable (or another input to existing clock enable logic).=20
When I have both reset and non-reset signals/variables in the same process =
(e.g. ram arrays, etc.), I use the following structure to avoid clock disab=
le on non-reset signals/variables:
process (clk, rst) is
begin
clocked: if rising_edge(clk) then
-- logic assignments here
end if clocked;
reset: if rst then=20
-- reset assignments here
end if reset;
end process;
Although this style works fine for the general case (when everything is res=
et), I do not use this style unless I actuall need it. The reason is, in th=
e conventional reset elsif clock structure, you will get synthesis warnings=
(from synplify at least) about feedback multiplexers on non-reset register=
s. You won't get those warnings for them if you use the method above. This =
also makes the above approach rarer, which stands out for the reviewer, whe=
re it gets extra attention to make sure that everything that should (can?) =
be reset is reset.
The same clock enable problem also happens when you use an "if reset else l=
ogic" structure for a synchronous reset. Nothing after that "else" executes=
when reset is true, which results in extra clock enable logic on non-reset=
registers. Use a similar approach to the above, by moving the (synchronous=
) reset assignments to their own if-statement just before the end of the cl=
ocked if-statement:
process (clk) is
begin
if rising_edge(clk) then
-- logic assignments here
if rst then
-- reset assignments here
-- to avoid clock enables
-- on non-reset registers
end if;
end if;
end process;
Strange how I didn't see any of this in that white paper written by the "ex=
perts"...
Andy
Article: 154278hi i would like to drive a Digital to analog converter(AD1933) with a cpld, here is what i'm trying to do: i have a micro controller that generate 25Mbps DAC data but is not capable of driving the DAC through high speed SPI(i need over 35MHz spi interface), so i decided to drive the dac with cpld or fpga, since i don't want to increase project cost by using fpga so i prefer to use cpld XC95XX(XC95144) for this application, i'm not sure if this cpld is capable of driving the dac at this rate, any one have any idea about the feasibility of this plan?? tnx in advance for help --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154279
Any help is appreciated. I get errors of the following sort:
"Multi-source in Unit <tst_1> on signal <ram<15><3>>; this signal is connec=
ted to multiple drivers."
The source for the entire unit in question is as follows:
module tst_1(
input rst,
input clk,
output [7:0] led
);
parameter s_0 =3D 2'b00;
parameter s_1 =3D 2'b01;
parameter s_2 =3D 2'b10;
parameter s_3 =3D 2'b11;
reg [1:0] state;
reg [7:0] ram[0:15];=20
reg [7:0] regs[0:7];
initial begin
state <=3D s_0;
end
always @(posedge clk) begin
if (rst =3D=3D 1'b1)
state <=3D s_0;
else begin
case (state)
s_0: begin
ram[15] <=3D 8'h00;
state <=3D s_1;
end
s_1: begin
regs[0] <=3D ~ram[8];
ram[15][0] <=3D 1'b1;
ram[15][1] <=3D 1'b0;
state <=3D s_2;
end
s_2: begin
ram[7] <=3D regs[0];
ram[15][2] <=3D ~regs[0][7];
ram[15][3] <=3D regs[0][3];
state <=3D s_3;
end
s_3: begin
ram[8] <=3D ram[7] ^ ram[15];
state <=3D s_1;
end
default:
state <=3D s_0;
endcase
end
end
assign led =3D regs[0];
endmodule
For the interested, I get multi-source errors on ram[15][3], ram[15][2], an=
d ram[15][0]... but not ram[15][1]. Since the signals in question are all d=
riven from different states within the same FSM, I am not sure why this is =
considered multiple drivers. I am sure this is something obvious to the wel=
l-informed. Any ideas?
Article: 154280Hi all, I have been trying to make the JTAG3-parallel cable with SPI work with spartan-3 board on red-hat linux(both from digilent) The Jtag3 seems to detect the fpga and flash in chain but it does not identify it. Have any of you run into this problem?? Also I am sure the s/w and the board works as I can program the same FPGA with same PC settings (using iMPACT) with the older JTAG-parallel cable from xilinx that supports 2.8V. please help!! Thanks a bunch, gokul --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154281
Hi, Is there anyway to estimate "PEAK power consumption" using an Xilinx XPower analyzer ? I think the "Summar" page shows AVERAGE power consumption. Thanks, Jeong-Gun --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154282
Hello, I am new to Xilinx and bash scripting. I am using Xilinx 13.4. I am trying to run implementation(ngdbuild, map, par etc) to create the bit file through a bash script, but I am getting an error. Following is the snippet of my error :- Running synthesis... bash -c "cd synthesis; ./synthesis.sh" xst -ifn system_xst.scr -intstyle silent Running XST synthesis ... PMSPEC -- Overriding Xilinx file </tools/Xilinx/13.4/ISE_DS/EDK/virtex5/data/virtex5.acd> with local file </tools/Xilinx/13.4/ISE_DS/ISE/virtex5/data/virtex5.acd> XST completed error status of previous command:0 => Starting xst: Xst log file is: no_file.syr Using xst file - no_file.xst ERROR:Xst:427 - Entry File no_file.xst not found Can I get some help on this? Thanks, Gaurav. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154283
Hi, I'm new to FPGAs but would like to get into the industry. Aside from building and playing around with toy projects, what can I do to help put me ahead of the other EE graduates? What kind of projects could be attempted with a starter kit that would put hairs on my chest so to speak? Thanks James --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154284
Hello 1. I'am a beginner in fpga.and want some help. I'am trying to write code for matching rising edges of two different pulse train signa,so that AND operation can be performed b/w them . synchronization is must for carrying the AND operation.Kindly suggest some idea. 2.how is it possible to generate signals at every rising egde of a given signal where the frequency of new signal is defined by the taking (present and just previous rising egde)for frequency calculation and new signal will be generated at this present rising edge of given signal ' seeking your valuable ideas. thanks in advance. regards --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154285
Any help is appreciated. I get multi-source errors on signals that are
being driven by different states in the same FSM and I'm not sure why. Here
is one of the multi-source errors that I get:
"Multi-source in Unit <tst_1> on signal <ram<15><3>>; this signal is
connected to multiple drivers."
and here is the source for the entire unit
module tst_1(
input rst,
input clk,
output [7:0] led
);
parameter s_0 = 2'b00;
parameter s_1 = 2'b01;
parameter s_2 = 2'b10;
parameter s_3 = 2'b11;
reg [1:0] state;
reg [7:0] ram[0:15];
reg [7:0] regs[0:7];
initial begin
state <= s_0;
end
always @(posedge clk) begin
if (rst == 1'b1)
state <= s_0;
else begin
case (state)
s_0: begin
ram[15] <= 8'h00;
state <= s_1;
end
s_1: begin
regs[0] <= ~ram[8];
ram[15][0] <= 1'b1;
ram[15][1] <= 1'b0;
state <= s_2;
end
s_2: begin
ram[7] <= regs[0];
ram[15][2] <= ~regs[0][7];
ram[15][3] <= regs[0][3];
state <= s_3;
end
s_3: begin
ram[8] <= ram[7] ^ ram[15];
state <= s_1;
end
default:
state <= s_0;
endcase
end
end
assign led = regs[0];
endmodule
For the interested, I get multi-source errors on ram[15][3], ram[15][2],
and ram[15][0]... but not ram[15][1]. I'm sure this must be something
obvious to the well-trained.
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 154286eulia <3676@embeddedrelated> wrote: > Hi, > Is there anyway to estimate "PEAK power consumption" using an Xilinx XPower > analyzer ? > I think the "Summar" page shows AVERAGE power consumption. What do you mean by peak? You have to have some capacitors on the supply lines, which will average out any transients. For CMOS, other than quiescient power (leakage current) power occurs when a gate changes state, and for a very short time. As you can't predict accurately enough the transition time, you can't predict how many will transition in a given femtosecond. Now, you might want the average over a somewhat shorter time scale, especially as you might want to know how to divide up the required capacitance, but peak really doesn't have much meaning. -- glenArticle: 154287
On 9/23/2012 2:03 PM, James823 wrote: > Hi, > I'm new to FPGAs but would like to get into the industry. Aside from > building and playing around with toy projects, what can I do to help put me > ahead of the other EE graduates? > What kind of projects could be attempted with a starter kit that would put > hairs on my chest so to speak? > > Thanks > James There are a lot of industry sectors that use FPGAs. You would do well to learn specifics about designs in sectors you are interested in working. For example, a lot of DOD folks do digital receiver designs. So if you want to work in DOD learning something about digital receivers would serve you well. Likewise there are key areas in each sector, so first figure out who you want to work for and then go for the in depth learning of their needs. This goes for all aspects of the job too. Before you interview with a company, learn as much as you can about the company and the job. RickArticle: 154288
On Sun, 23 Sep 2012 00:57:27 -0500, nba83 wrote: > hi i would like to drive a Digital to analog converter(AD1933) with a > cpld, here is what i'm trying to do: i have a micro controller that > generate 25Mbps DAC data but is not capable of driving the DAC through > high speed SPI(i need over 35MHz spi interface), so i decided to drive > the dac with cpld or fpga, > since i don't want to increase project cost by using fpga so i prefer to > use cpld XC95XX(XC95144) for this application, i'm not sure if this cpld > is capable of driving the dac at this rate, any one have any idea about > the feasibility of this plan?? > tnx in advance for help How are you going to get data into your CPLD at that rate? Parallel? Some other serial interface that also needs to run at 35MHz or more? Your feasibility may break up on other rocks than whether the CPLD is up to it. Having said that -- to my beginner's eyes a parallel in, serial out, 35MHz SPI should be doable with a part like that. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 154289
On 9/23/2012 1:57 AM, nba83 wrote: > hi > i would like to drive a Digital to analog converter(AD1933) with a cpld, > here is what i'm trying to do: i have a micro controller that generate > 25Mbps DAC data but is not capable of driving the DAC through high speed > SPI(i need over 35MHz spi interface), so i decided to drive the dac with > cpld or fpga, > since i don't want to increase project cost by using fpga so i prefer to > use cpld XC95XX(XC95144) for this application, i'm not sure if this cpld is > capable of driving the dac at this rate, any one have any idea about the > feasibility of this plan?? > tnx in advance for help Without looking at the data sheet, I am pretty sure these parts can drive a 35 MHz serial shift register. 35 MHz is pretty slow for any programmable logic part. How will the CPLD talk to the micro? I assume you plan to use a parallel, memory mapped interface? Can your MCU keep up with the data speed? RickArticle: 154290
On 9/23/2012 4:27 PM, rickman wrote: > On 9/23/2012 1:57 AM, nba83 wrote: >> hi >> i would like to drive a Digital to analog converter(AD1933) with a cpld, >> here is what i'm trying to do: i have a micro controller that generate >> 25Mbps DAC data but is not capable of driving the DAC through high speed >> SPI(i need over 35MHz spi interface), so i decided to drive the dac with >> cpld or fpga, >> since i don't want to increase project cost by using fpga so i prefer to >> use cpld XC95XX(XC95144) for this application, i'm not sure if this >> cpld is >> capable of driving the dac at this rate, any one have any idea about the >> feasibility of this plan?? >> tnx in advance for help > > Without looking at the data sheet, I am pretty sure these parts can > drive a 35 MHz serial shift register. 35 MHz is pretty slow for any > programmable logic part. > > How will the CPLD talk to the micro? I assume you plan to use a > parallel, memory mapped interface? Can your MCU keep up with the data > speed? > > Rick BTW, there are some very low cost FPGAs available, around $3. Check out the Lattice ice40 series. RickArticle: 154291
"nba83" <3224@embeddedrelated> wrote: >hi >i would like to drive a Digital to analog converter(AD1933) with a cpld, >here is what i'm trying to do: i have a micro controller that generate >25Mbps DAC data but is not capable of driving the DAC through high speed >SPI(i need over 35MHz spi interface), so i decided to drive the dac with >cpld or fpga, >since i don't want to increase project cost by using fpga so i prefer to >use cpld XC95XX(XC95144) for this application, i'm not sure if this cpld is >capable of driving the dac at this rate, any one have any idea about the >feasibility of this plan?? It shouldn't be a problem. I use these CPLDs for rescaling VGA resolution TFT displays at reduced color depths. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 154292
On 9/23/2012 2:44 AM, smileforthecamerahotshot@gmail.com wrote: > Any help is appreciated. I get errors of the following sort: > > "Multi-source in Unit <tst_1> on signal <ram<15><3>>; this signal is connected to multiple drivers." > > The source for the entire unit in question is as follows: > > module tst_1( > input rst, > input clk, > output [7:0] led > ); > parameter s_0 = 2'b00; > parameter s_1 = 2'b01; > parameter s_2 = 2'b10; > parameter s_3 = 2'b11; > > reg [1:0] state; > reg [7:0] ram[0:15]; > reg [7:0] regs[0:7]; > > initial begin > state <= s_0; > end > > always @(posedge clk) begin > if (rst == 1'b1) > state <= s_0; > else begin > case (state) > s_0: begin > ram[15] <= 8'h00; > state <= s_1; > end > s_1: begin > regs[0] <= ~ram[8]; > ram[15][0] <= 1'b1; > ram[15][1] <= 1'b0; > state <= s_2; > end > s_2: begin > ram[7] <= regs[0]; > ram[15][2] <= ~regs[0][7]; > ram[15][3] <= regs[0][3]; > state <= s_3; > end > s_3: begin > ram[8] <= ram[7] ^ ram[15]; > state <= s_1; > end > default: > state <= s_0; > endcase > end > end > assign led = regs[0]; > endmodule > > For the interested, I get multi-source errors on ram[15][3], ram[15][2], and ram[15][0]... but not ram[15][1]. Since the signals in question are all driven from different states within the same FSM, I am not sure why this is considered multiple drivers. I am sure this is something obvious to the well-informed. Any ideas? > Perhaps ram[15][1] is never driven to a value other than zero and has been "replaced by logic." What tools are you using, and what version? I have seen a lot of bogus multi-source messages from Xilinx XST especially when using arrays and loops. Theoretically any number of assignments in the same process should never create a multi-source error. -- GaborArticle: 154293
smileforthecamerahotshot@gmail.com wrote: > Any help is appreciated. I get errors of the following sort: > "Multi-source in Unit <tst_1> on signal <ram<15><3>>; this > signal is connected to multiple drivers." It isn't so obvious to me how to read this. It seems that it should depend on what is available as RAM resources. > The source for the entire unit in question is as follows: > module tst_1( > input rst, > input clk, > output [7:0] led > ); > parameter s_0 = 2'b00; > parameter s_1 = 2'b01; > parameter s_2 = 2'b10; > parameter s_3 = 2'b11; > reg [1:0] state; > reg [7:0] ram[0:15]; > reg [7:0] regs[0:7]; > initial begin > state <= s_0; > end > always @(posedge clk) begin > if (rst == 1'b1) > state <= s_0; > else begin > case (state) > s_0: begin > ram[15] <= 8'h00; OK, being inside the always @(posedge clk) this is a synchronous RAM. Personally, I do like writing state machines with the state logic inside, but some tell me that the state selection and state action should be separate blocks. Normally I don't believe the difference matters, but it isn't so obvious to me in the case of ram. > state <= s_1; > end > s_1: begin > regs[0] <= ~ram[8]; > ram[15][0] <= 1'b1; > ram[15][1] <= 1'b0; Since only two bits of ram are being changed, this requires either separate RAMs or separate write enable bits. > state <= s_2; > end > s_2: begin > ram[7] <= regs[0]; > ram[15][2] <= ~regs[0][7]; > ram[15][3] <= regs[0][3]; Now you change both ram[7] and ram[15] in the same state, so it requires dual port write access. That is fine, but is much less common than dual port read. > state <= s_3; > end > s_3: begin > ram[8] <= ram[7] ^ ram[15]; In this case, dual port read and separate write port at the same time. > state <= s_1; > end > default: > state <= s_0; > endcase > end > end > assign led = regs[0]; > endmodule Maybe it doesn't have anything to do with the problem, but are you sure that the target architecture supports RAM with two read and two write ports? -- glenArticle: 154294
On Sunday, September 23, 2012 5:58:45 PM UTC-7, Gabor wrote: >=20 > > Any help is appreciated. I get errors of the following sort: >=20 > > >=20 > > "Multi-source in Unit <tst_1> on signal <ram<15><3>>; this signal is co= nnected to multiple drivers." >=20 > > >=20 > > The source for the entire unit in question is as follows: >=20 > > >=20 > > module tst_1( >=20 > > input rst, >=20 > > input clk, >=20 > > output [7:0] led >=20 > > ); >=20 > > parameter s_0 =3D 2'b00; >=20 > > parameter s_1 =3D 2'b01; >=20 > > parameter s_2 =3D 2'b10; >=20 > > parameter s_3 =3D 2'b11; >=20 > > >=20 > > reg [1:0] state; >=20 > > reg [7:0] ram[0:15]; >=20 > > reg [7:0] regs[0:7]; >=20 > > >=20 > > initial begin >=20 > > state <=3D s_0; >=20 > > end >=20 > > >=20 > > always @(posedge clk) begin >=20 > > if (rst =3D=3D 1'b1) >=20 > > state <=3D s_0; >=20 > > else begin >=20 > > case (state) >=20 > > s_0: begin >=20 > > ram[15] <=3D 8'h00; >=20 > > state <=3D s_1; >=20 > > end >=20 > > s_1: begin >=20 > > regs[0] <=3D ~ram[8]; >=20 > > ram[15][0] <=3D 1'b1; >=20 > > ram[15][1] <=3D 1'b0; >=20 > > state <=3D s_2; >=20 > > end >=20 > > s_2: begin >=20 > > ram[7] <=3D regs[0]; >=20 > > ram[15][2] <=3D ~regs[0][7]; >=20 > > ram[15][3] <=3D regs[0][3]; >=20 > > state <=3D s_3; >=20 > > end >=20 > > s_3: begin >=20 > > ram[8] <=3D ram[7] ^ ram[15]; >=20 > > state <=3D s_1; >=20 > > end >=20 > > default: >=20 > > state <=3D s_0; >=20 > > endcase >=20 > > end >=20 > > end >=20 > > assign led =3D regs[0]; >=20 > > endmodule >=20 > > >=20 > > For the interested, I get multi-source errors on ram[15][3], ram[15][2]= , and ram[15][0]... but not ram[15][1]. Since the signals in question are a= ll driven from different states within the same FSM, I am not sure why this= is considered multiple drivers. I am sure this is something obvious to the= well-informed. Any ideas? >=20 > > >=20 > Perhaps ram[15][1] is never driven to a value other than zero and has >=20 > been "replaced by logic." What tools are you using, and what version? >=20 > I have seen a lot of bogus multi-source messages from Xilinx XST >=20 > especially when using arrays and loops. Theoretically any number >=20 > of assignments in the same process should never create a multi-source >=20 > error. >=20 >=20 >=20 > -- Gabor I am using Xilinx ISE WebPACK v12.4 (nt64). I also tried this using ISE Web= PACK 9.2i 32-bit and get the same errors. I have tried targeting an XC3S500= E and an XC3S1600E. One thing that I noticed is that if I change the s_0 st= ate to do this "ram[15][7:0] <=3D 8'h00;" instead of this "ram[15] <=3D 8'h= 00;" then I get no errors. I don't understand this.Article: 154295
> >How are you going to get data into your CPLD at that rate? Parallel? >Some other serial interface that also needs to run at 35MHz or more? > >Your feasibility may break up on other rocks than whether the CPLD is up >to it. > >Having said that -- to my beginner's eyes a parallel in, serial out, >35MHz SPI should be doable with a part like that. > >-- >Tim Wescott >Control system and signal processing consulting >www.wescottdesign.com > I want to feed data in parallel (8bit) to CPLD, buffer it for about 100 bytes, and then start to drive SPI Out. I am some how concerned about the speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it is -10C(means 10nsec delay for IO routs), does this delay impose any problem? Since I want to drive the CPLD with 100MHZ oscillator clk input, and by clk dividing generate a 50 or 40MHz clk for SPI. tnx for any helpful comments :) --------------------------------------- Posted through http://www.FPGARelated.comArticle: 154296
On 09/24/2012 08:09 AM, nba83 wrote: > I want to feed data in parallel (8bit) to CPLD, buffer it for about 100 > bytes, and then start to drive SPI Out. I am some how concerned about the > speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it is > -10C(means 10nsec delay for IO routs), does this delay impose any problem? > Since I want to drive the CPLD with 100MHZ oscillator clk input, and by clk > dividing generate a 50 or 40MHz clk for SPI. > tnx for any helpful comments :) The problem isn't going to be the speed, but where the CPLD is going to store the 100 bytes. The XC95144XL only has 144 bits of storage total.Article: 154297
>On 09/24/2012 08:09 AM, nba83 wrote:
>
>> I want to feed data in parallel (8bit) to CPLD, buffer it for about 100
>> bytes, and then start to drive SPI Out. I am some how concerned about
the
>> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it is
>> -10C(means 10nsec delay for IO routs), does this delay impose any
problem?
>> Since I want to drive the CPLD with 100MHZ oscillator clk input, and by
clk
>> dividing generate a 50 or 40MHz clk for SPI.
>> tnx for any helpful comments :)
>
>The problem isn't going to be the speed, but where the CPLD is going to
>store the 100 bytes. The XC95144XL only has 144 bits of storage total.
>
>
I have implemented a 1k byte dual port ram in this cpld logic in xilinx
ise, but i havn't tested it yet. I have not added the DAC driver to it yet,
i'm not sure if this cpld is enough for these modules. here is the
implementation for RAM:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity dpram_4x2045 is
Port ( DIN : in std_logic_vector(7 downto 0);
RE_ADDRESS : in std_logic_vector(10 downto 0);
wr_address :in std_logic_vector(10 downto 0);
CLCK_wr : in std_logic;
CLCK_re : in std_logic;
We : in std_logic;
Re : in std_logic;
dout : out std_logic_vector(7 downto 0));
end dpram_4x2045 ;
architecture Behavioral of dpram_4x2045 is
type my_data is array (0 to 2048)of std_logic_vector(7 downto 0) ;
signal rom: my_data;
begin
process (clck_wr)--write
begin
if (clck_wr'event and clck_wr = '0') then
if (we = '1') then
rom(conv_integer(WR_address)) <= din;
end if;
end if;
end process;
process (clck_re)--read
begin
if (clck_re'event and clck_re = '1') then ---e
if (Re = '1') then
dout<=rom(conv_integer(RE_address));
end if;
end if;
end process;
end Behavioral;
and the other module will receive bytes from parallel port and write it in
buffer, after writing 100 bytes, spi out module is enabled. and send out
data bytes
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 154298On Mon, 24 Sep 2012 06:00:15 -0500 "nba83" <3224@embeddedrelated> wrote: > >On 09/24/2012 08:09 AM, nba83 wrote: > > > >> I want to feed data in parallel (8bit) to CPLD, buffer it for about 100 > >> bytes, and then start to drive SPI Out. I am some how concerned about > the > >> speed grade of the CPLD I intend to use(XC95144XL-TQG144-10C), it is > >> -10C(means 10nsec delay for IO routs), does this delay impose any > problem? > >> Since I want to drive the CPLD with 100MHZ oscillator clk input, and by > clk > >> dividing generate a 50 or 40MHz clk for SPI. > >> tnx for any helpful comments :) > > > >The problem isn't going to be the speed, but where the CPLD is going to > >store the 100 bytes. The XC95144XL only has 144 bits of storage total. > > > > > > I have implemented a 1k byte dual port ram in this cpld logic in xilinx > ise, but i havn't tested it yet. I have not added the DAC driver to it yet, > i'm not sure if this cpld is enough for these modules. here is the > implementation for RAM: > You've written behavioral VHDL that describes a dual-port block RAM. That's lovely and all, but have you checked the CPLD datasheet and confirmed that there is a block RAM resource on the chip that will do that? You could also write VHDL describing a unicorn, but you'd be hard pressed to make it pass synthesis. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 154299
On Sun, 23 Sep 2012 13:03:13 -0500
"gaurav3110" <3677@embeddedrelated> wrote:
>
> Hello,
>
>
>
> I am new to Xilinx and bash scripting. I am using Xilinx 13.4. I am trying
> to run implementation(ngdbuild, map, par etc) to create the bit file
> through a bash script, but I am getting an error. Following is the snippet
> of my error :-
>
> Running synthesis...
>
> bash -c "cd synthesis; ./synthesis.sh"
> xst -ifn system_xst.scr -intstyle silent
> Running XST synthesis ...
> PMSPEC -- Overriding Xilinx file
> </tools/Xilinx/13.4/ISE_DS/EDK/virtex5/data/virtex5.acd> with local file
> </tools/Xilinx/13.4/ISE_DS/ISE/virtex5/data/virtex5.acd>
> XST completed
> error status of previous command:0
> => Starting xst: Xst log file is: no_file.syr
> Using xst file - no_file.xst
>
Yeah, it's looking for some reason for an XST script file called
no_file.xst, and can't find it. The problem is probably in your
system_xst.scr file (which I wouldn't swear up and down is allowed to
have an extension other than .xst)
I use a Makefile scripted flow for all my Xilinx projects. On the
most recent one I'm working on, my command line call is:
xst -ifn top_level_gen.xst -ofn 28C940A-xst.log
And this is my top_level_gen.xst:
set -xsthdpdir ./_xst
set -tmpdir ./_xst/tmp
run
-resource_sharing NO
-keep_hierarchy SOFT
-glob_opt allclocknets
-opt_level 2
-opt_mode speed
-rtlview yes
-bufg 0
-ifn 28C940A.prj
-ofn 28C940A
-top top_level
-iobuf YES
-uc synth/28A940.xcf
-p xc3s1500-4-fg456
-generics {REV='A' CODE=28940 STAMP=1347396632}
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
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