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
Brannon wrote: "I posted a few hours ago but it has yet to show so I'll try again. Most modern square root algorithms do multiple bits per clock cycle. There was a great paper out of Thailand (I believe) a few years back with a very simple square root algorithm that does two bits per clock cycle. I was unable to locate the paper but I did find some C code I used to test it. Using it I was able to do a fine FP square root operator using half the resources of Xilinx and having half the latency for both pipelined and unpipelined versions. I actually think I could cut the latency in half again if I worked at it and used just a few more resources to do two adds in a clock cycle. If anyone recognizes the C code below, please post the source! " I have read the paper out of Thailand, but its credit should go to the algorithm inventors: Y. Li and W. Chu of The University of Aizu, Japan. Please notice in paper of Thailand there is a serious typo in the algorithm in Fig. 1. in the loop: R = R - ((Q<<2) or 3); It should read: R = R + ((Q<<2) or 3); But the expression by Brannon in C in the third email of this thread is right. WengArticle: 99476
Antti, OK, Lattice is real, sampling with demo boards that are available. Good. Austin Antti wrote: > Hi Austin, > > we had Lattice vice president visiting here last week. The SC parts are > real. We did however not got the SC PCIe card loaner yet, all the > boards are out, so we are on waitinglist to get to play with the SC > board - we are hoping to test 4 lane PCIe on it. > > 1 maco can do 4 lane PCIe, this IP core solution comes from Lattice, 8 > lane PCIe solution will be offered by northwest > > SC25 parts should be available, the promise was sample delivery in 3 > weeks max if I recall correctly. > > So hum, I can assume that the parts actually are real, if the vice > talked about boards that are in evaluation by some clients, then there > must be parts on them :), but until today I havent seen and SC or ECP > silicon yet. > > EC, XP, machXO are all real (I have used EC and XP), as of RAM based I > would skip EC/ECP and only use ECP2, for nonvolatile solutions macXO if > 8by8 mm 0.5mm BGA is needed for space constraints or XP3/XP3 (cheaper > than large machXO). > > as of SC more, the SERDES is specified up to 3.4G (but is expected to > work up to 3.8G) > > low cost ECP2 is specified to work with DDR2 400, and can possible be > speficied up to DDR2 530 (that depends if... could be, not guaranteed > yet). For low cost FPGA its pretty damn good. I have on board on my > desk where Spartan3 was considered, but cancelled because of (possible) > problems with DDR2 memory. > >>From Lattice FAE (was visiting today) well he was very surprised to > hear about my fpga logic fabric measurements indicating that S3 is WAY > slower than V4 despite using the same technology. Lattice is not using > performance reduction on ECP2 so you get the low cost FPGA that works > at fabric speed that are normal for the technology. Eg high performance > and low cost. > > Of course there are things Lattice does badly also, ECP2 has > nonvolatile OTP securtiy key, but SC does not have it ! but it would > most useable in SC.. > > Ah, SC15 is possible the only modern high end PFGA with SERDES that is > available in FT256 (or same size) footprint - FX12 that is in same > sized package doesnt have serdes. > > hum, Lattice SoC design environment is coming too, if someone is > wondering :) uses Wishbone for interconnect. > > Was it On topic now for the OP? > > Antti >Article: 99477
Hi all,
I am reading the book "Writing Testbench". And write the code below:
It seems the code is blocked in the task "@ (posedge clk)", and the
task never return the "valid", why?
I guess task cannot pass the continuous clk value?
//--------test.v-------------
module test;
reg clk;
integer i;
reg [7:0] input1,input2;
reg [7:0] valid1;
test_lib test_lib();
always begin
#50 clk <= 1'b0;
#50 clk <= 1'b1;
end
initial begin
for (i=1;i<=8;i=i+1)
begin
input1 = i;
input2 = i;
begin
test_lib.compare_vector(clk,input1,input2,valid1);
end
@ (posedge clk);
end
end
endmodule
//---------end test.v--------------
//----------test_lib.v-------------
module test_lib;
task automatic compare_vector;
input clk;
input [7:0] input1;
input [7:0] input2;
output valid;
begin
$write("p1\n");
@ (posedge clk)
valid = (input1==input2);
$write("p2\n");
end
endtask
endmodule
//-------end test_lib.v------------
Any suggestions will be appreciated!
Best regards,
Davy
Article: 99478
Hi all,
Sometimes I have to write long DFF chain like below:
//------code--------------
...
reg [7:0] DFF0,DFF1,DFF2,...DFF50;
always@(posedge clk)
if(rst)
begin
DFF0 <= 0;
...
DFF50 <= 0;
end
else
begin
DFF0 <= INPUT;
...
DFF50 <= DFF49;
end
//------code end-----------
It's too long, is there any good compact style?
Any suggestions will be appreciated!
Best regards,
Davy
Article: 99479"Brannon" <brannonking@yahoo.com> writes: > This post is a bit of a flame, but seriously, JTAG has got to go. [...] > 1. Support for a lot of chips, say 2048 of them. JTAG supposedly > supports 16 chips. Yeah, right. The 5MHz clock signal dies out after > three or four. The 200KHz signal dies after eight or nine. Have you heard of buffering and multiplexing? I've seen boards with over 100 JTAG devices, with a few clock buffers and a few multiplexers and signal buffers to tie everything together. Then a few dozen of these boards are similarly mulitplexed by the backplane circuitry. here's no way in hell that I'd want 2048 chips in one JTAG chain anyhow. Life's too short. On the other hand, a new standard for JTAG multiplexing controlled over the JTAG itself would be quite useful. If such a standard existed, you'd probably be able to buy cheap commodity JTAG buffer/mux chips in a wide variety of port counts. > This will > require some strong signals with error correction, but, heck, if a > basic ethernet layer can do it.... You mean the old thick-cable 10Base5 Ethernet? That only supported a maximum of 100 nodes per segment. Beyond that, you needed a repeater. Also, each node needed an expensive transceiver (vampire tap). If you were thinking of thin coax 10Base2, that only supported 30 nodes per segment. Neither technology is even vaguely comparable to what you seem to be asking for. Everyone was happy to abandon these in favor of 10BaseT (and later, 100BaseT) point-to-point links? No, we definitely don't want to bring bussed Ethernet back. Using error correction would be overkill, and would add way too much circuitry to devices. Just put a basic frame check for error detection. A parity bit or a CRC-16 should work quite nicely for that. Since you'd use multiplexing rather than putting 2048 chips in one chain, you'd be able to afford to resend a frame rather than depending on the chip to correct errors. (Note that the frame I'm talking about isn't necessarily any relation to a Xilinx FPGA configuration frame.)Article: 99480
Chris Briggs wrote: > The thing is that MODEL_TECH isn't an environment variable, it's a > Verilog macro that Modelsim automatically defines for you. It's the > same as if you did `define FOO in your code or +define+FOO on the vlog > command line. > > Your choices are to pass your settings on the vlog command line > (+define+MY_VARIABLE=1) or write them to a file (`define MY_VARIABLE 1) > that gets compiled in with your testbench. > > -cb The vlog option is exactly what I was looking for. My Verilog code is shared with other EDK projects (as part of an EDK pcore), but the do script that I use is specific to each EDK project. I just tried your suggestion and it works. This is what I had to add in my .do script (for those who interesting in getting the syntax right): # Snippet of my do script do system.do # Invoke EDK generated do script first vlog -incr -work my_pcore path_to_verilog_file +define+MY_VARIABLE=1 . . . Now, I can de-couple the project specific settings from the shared Verilog code. Another way I could have done this was to set it as a parameter that is visible on the top-level MHS file of the EDK project. However, if I change the variable, I'd have to re-generate the simulation models in EDK, which takes more time. Commenting out the above vlog line the .do script is much faster. Thanks again for both of your assistance. NNArticle: 99481
Austin Lesea wrote: > Antti, > > OK, Lattice is real, sampling with demo boards that are available. > > Good. Shouldn't that have been 'bummer!' ? :) -jgArticle: 99482
Ray Andraka wrote: > > For one or two it seems to work. For many, it slows PAR way down > and usually won't find a solution where all the maxdelays get met > Ok, that sounds (dare I say) about par for the course... Have you ever gotten anywhere in convincing Xilinx to add a flag to the router to restore the old, more consistent, behavior? > not to mention making the UCF a nightmare. I just stuck the MAXDELAYs in the source near the net keep directives. I have enough UCF nightmares already; on the bright side, at least they haven't made the UCF a binary file yet :) BrianArticle: 99483
dotnetters@gmail.com wrote: > Hello All! > (virtex board)... we had to write a hardware stack. After having made it work, > we thought of optimizing the design and hence removed a few states and > reduced the no. of states from 8 to 4. The older code was getting > synthesized in around 20 mins, but the new code takes hours together to > get synthesized, and so does the PAR. How can we reduce the synthesis > time? Why is that the code which took lesser time to get synthesized is > now taking longer? I'm going to assume here that by hardware stack, you mean a pushdown stack involving RAM and pointers and all that. I ran into a problem yesterday (with ROM, not RAM, but may be the same root cause). The ROM was inferred by VHDL code, not generated with Coregen. The description, although it was perfectly valid, was not one that XST recognized as being synthesizable into BlockRAM, and the RAM (ROM) was being put into distributed memory instead. This absolutely kills performance of both XST and PAR. What XST could not handle was the addition of a reset (init value) to the code description. Although the part (Spartan 3) has this functionality, XST can't handle it. So check your synthesis report, see whether your RAM is going into BRAM or distRAM. Side note: I see that XST now does support inference of Dual(write)Port BRAMs as of 8.1i (I just loaded SP 3, out today). Kudos to Xilinx, keep it coming, please add the Set/Reset function to XST's BRAM inference repertoire soonest! HTH, JohnArticle: 99484
Brian Davis wrote: > Ray Andraka wrote: > >>For one or two it seems to work. For many, it slows PAR way down >>and usually won't find a solution where all the maxdelays get met >> > > Ok, that sounds (dare I say) about par for the course... > > Have you ever gotten anywhere in convincing Xilinx to add a flag > to the router to restore the old, more consistent, behavior? From a Software Architecture viewpoint, the _sensible_ thing would be to allow a selection of router by resource, and also an order. That way, you could tell it to use a simple, direct path router on the fast nets first, and then the speed-driven router on the other nets.. I fear the 'old router' code is long lost, in the mists of time... > >>not to mention making the UCF a nightmare. > > > I just stuck the MAXDELAYs in the source near the net keep directives. > > I have enough UCF nightmares already; on the bright side, at least > they haven't made the UCF a binary file yet :) ssssshhh ! - someone in Xilinx might think that's a good idea! -jgArticle: 99485
Hi all,
I am reading the book "Writing Testbench" and found my previous
testbench style is RTL.
Can I change Verilog RTL Testbench to Behavioral Testbench, is the
below code right?
//---- RTL style---
Always@(posedge clk)
If(EN)
...
//------------------
//----Behavioral style---
Always begin
wait(EN);
@(posedge clk);
...
end
//-----------------------
Is there any other better Behavioral style?
Any suggestions will be appreciated!
Best regards,
Davy
Article: 99486Hi, I've faced with the following annoying bug with ISE webpack 8.1.02i's test bench waveform editor. When I click on any of the bus lines to set it's value, or when I right click it and select Set Value, the window should puput allowing to enter the value in the desired base. The problem is that the window appears, but every time I set a value, it shifts the input box to the left. I did not bother moving it to the center, so now it eventually shifted beyond the screen!!! I cannot bring it back. ALT+space window controlling shortcuts are not available! .. That's quite a funny, but really annoying bug. I am out of the options to set values in other bases. Let me know if you've faced the same problem or know how to fix it. ThanksArticle: 99487
"Davy" <zhushenli@gmail.com> wrote in message news:1143252117.350503.262470@i39g2000cwa.googlegroups.com... > Hi all, > > Sometimes I have to write long DFF chain like below: > > //------code-------------- > ... > reg [7:0] DFF0,DFF1,DFF2,...DFF50; > > always@(posedge clk) > if(rst) > begin > DFF0 <= 0; > ... > DFF50 <= 0; > end > else > begin > DFF0 <= INPUT; > ... > DFF50 <= DFF49; > end > > //------code end----------- > It's too long, is there any good compact style? Can't you declare it as : reg [7:0] DFF[0:50]; and then use for loops with the loop counter declared as an integer? I believe this is synthesizeable. Am I right?Article: 99488
You could make another verilog95 way:
reg [8*51-1:0] DFFs;
wire [7:0] DFF0,DFF1,DFF2,...DFF50;
assign {DFF50, DFF49, ..., DFF0} = DFFs;
always @(posedge clk) begin
if(rst) DFFs <= {51{8'h00}};
else begin
DFFs <= DFFs << 8;
DFFs[7:0] <= INPUT;
end
end
Of course you can omit assigning and use only required bits from vector
DFFs.
Article: 99489Ben, Yes you're minipci design worked on my pc, i did somehow used it as a reference, and somehow i have managed to port it into my new design, unfortunately the former did'nt worked on all PC on our lab. Back to the Topic, i have finished the the new design. And i think it did comply on PCI 2.1 spec or even on 3.0 since i slightly used it as reference for the New State Machine design. Anyhow, it still doesnt work. I use Quartus-II 5.1 software for synthesis and simulation, other people say it should use HDL-Simulation tools, or even Signal analyzers... Also i'm done with cfg_hit and addr_hit, i put it on another module, Address Decoder module. This is the simulation waveform if you want to see: http://i1.tinypic.com/s5lj54.gif note with regards to screenshot: Will the bus master work with this kind of target (i.e. having Medium Devsel timing)? and with other timing of signals in that screenshot. --- Young LeafArticle: 99490
> > On the other hand, a new standard for JTAG multiplexing controlled over > the JTAG itself would be quite useful. If such a standard existed, you'd > probably be able to buy cheap commodity JTAG buffer/mux chips in a wide > variety of port counts. > I've used the JTS06 six port scan bridge with success from these people : http://www.firecron.com/ it's has six chains and is controlled over JTAG. Similar 3 port devices available from National /MikeJArticle: 99491
Hello, ALL! In our design we are planning to use Spartan-3E in PCI 33/66 environment. We have developed our own PCI core. Since the code is completely RTL and does not have any platform-specific features we were able to test it with existing Altera ACEX-1K PCI33 board. Running on speed grade 2 Altera ACEX-1K device our core has about 1.5-2ns out of 7ns Tsu margin and even more for Tout. Now for production design we are planning to move to Xilinx Spartan-3E 500 FPGA. During detailed investigation of FT256 package we found several strange pins, marked as IRDY1, TRDY1, IRDY2 and TRDY2. Do these pins have any significant meaning for PCI designs? Unfortunately, I did not find any explanations in Spartan-3E datasheet, neither in accompanying application notes. With best regards, Vladimir S. MirgorodskyArticle: 99492
<v_mirgorodsky@yahoo.com> schrieb im Newsbeitrag news:1143294891.415443.17250@v46g2000cwv.googlegroups.com... > Hello, ALL! > > In our design we are planning to use Spartan-3E in PCI 33/66 > environment. We have developed our own PCI core. Since the code is > completely RTL and does not have any platform-specific features we were > able to test it with existing Altera ACEX-1K PCI33 board. Running on > speed grade 2 Altera ACEX-1K device our core has about 1.5-2ns out of > 7ns Tsu margin and even more for Tout. Now for production design we are > planning to move to Xilinx Spartan-3E 500 FPGA. During detailed > investigation of FT256 package we found several strange pins, marked as > IRDY1, TRDY1, IRDY2 and TRDY2. Do these pins have any significant > meaning for PCI designs? Unfortunately, I did not find any explanations > in Spartan-3E datasheet, neither in accompanying application notes. > > With best regards, > Vladimir S. Mirgorodsky > there is undocumented PCI_LOGIC primitive in S3e, so the special pins should be used with that special primitive. there is no official info but several people/companies have 'reverse engineered' the PCI_LOGIC and are actually using it (or able to use it) AnttiArticle: 99493
On 24 Mar 2006 03:31:51 -0800, dotnetters@gmail.com wrote: >Hello There! >We need to profile our software program that runs on the MicroBlaze >SCP. We referred to the Platform Studio user guide. It says so: > >"The following steps illustrate profiling on a MicroBlaze program. The >system has BRAM >and External Memory. The system has an opb_timer, and the Interrupt >signal is directly >connected to MicroBlaze External Interrupt signal. The opb_timer is >used as the profile >timer on MicroBlaze." > >I think the addtion of opb_timer can be done froom the "Add/Edit cores" >dialog (correct me if i'm wrong). But how do i "directly connect" the >interrupt signal to MicroBlaze External Interrupt signal? If you are already using interrupts on the Microblaze, it would be better to connect the timer interrupt to the opb_intc core along with the other interrupt sources ... see what happens to them for an example. If it's your only interrupt, you can connect it in the "Ports" tab of "add/edit cores"; use the same signal name for the opb_timer interrupt port, and the Microblaze interrupt input port. Or you can edit the "MHS" file by hand to do the same thing. (Watch what the "Add/Edit Cores" does to the .mhs file, to see how it is done) - Brian - BrianArticle: 99494
> <v_mirgorodsky@yahoo.com> schrieb im Newsbeitrag > news:1143294891.415443.17250@v46g2000cwv.googlegroups.com... > > Hello, ALL! > > > > In our design we are planning to use Spartan-3E in PCI 33/66 > > environment. We have developed our own PCI core. Since the code is > > completely RTL and does not have any platform-specific features we were > > able to test it with existing Altera ACEX-1K PCI33 board. Running on > > speed grade 2 Altera ACEX-1K device our core has about 1.5-2ns out of > > 7ns Tsu margin and even more for Tout. Now for production design we are > > planning to move to Xilinx Spartan-3E 500 FPGA. During detailed > > investigation of FT256 package we found several strange pins, marked as > > IRDY1, TRDY1, IRDY2 and TRDY2. Do these pins have any significant > > meaning for PCI designs? Unfortunately, I did not find any explanations > > in Spartan-3E datasheet, neither in accompanying application notes. > > > > With best regards, > > Vladimir S. Mirgorodsky > > > > Antti Lukats wrote: > > there is undocumented PCI_LOGIC primitive in S3e, so the special pins should > be used with that special primitive. there is no official info but several > people/companies have 'reverse engineered' the PCI_LOGIC and are actually > using it (or able to use it) > > Antti Hello Antti, and thanks for your response. So, that seems that I will not have any advantages using those pins in my design :( I was hoping to avoid whatever floorplanning stuff during migration to PCI66, as I did for PCI33. Is there any possibility, that Xilinx will disclose functionality behind those pins in the future? Is there any recommended layouts available for PCI33/66? With best regards, Vladimir S. MirgorodskyArticle: 99495
Task arguments are passed by value and hence is what you have seen/observed. Your option will be to pass the clk as input to test_lib module. HTH Ajeetha, CVC www.noveldv.comArticle: 99496
Nope, A healthy competitve marketplace needs competition. Austin Jim Granville wrote: > Austin Lesea wrote: > >> Antti, >> >> OK, Lattice is real, sampling with demo boards that are available. >> >> Good. > > > Shouldn't that have been 'bummer!' ? :) > > -jg >Article: 99497
v_mirgorodsky@yahoo.com wrote: > and thanks for your response. So, that seems that I will not have any > advantages using those pins in my design :( I was hoping to avoid > whatever floorplanning stuff during migration to PCI66, as I did for > PCI33. Is there any possibility, that Xilinx will disclose > functionality behind those pins in the future? Is there any recommended > layouts available for PCI33/66? Look with google groups for that subject. There was an interesting discussion November 2005. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 99498
Vladamir, The PCI application has odd timing requirements. As a consequence, to be sure we can always meet the requirements, Xilinx has at various times had hardened bits of logic "just in case" the final silicon was not capable of meeting a particular PCI requirement. If you would like more information, please email me directly. Since these pins are undocumented, looks like there were not needed. I am not in the Spartan Design Team, so I will go reseach it further if you need. The Virtex Design Team has done this also (at various times), so it is nothing new. Austin v_mirgorodsky@yahoo.com wrote: > Hello, ALL! > > In our design we are planning to use Spartan-3E in PCI 33/66 > environment. We have developed our own PCI core. Since the code is > completely RTL and does not have any platform-specific features we were > able to test it with existing Altera ACEX-1K PCI33 board. Running on > speed grade 2 Altera ACEX-1K device our core has about 1.5-2ns out of > 7ns Tsu margin and even more for Tout. Now for production design we are > planning to move to Xilinx Spartan-3E 500 FPGA. During detailed > investigation of FT256 package we found several strange pins, marked as > IRDY1, TRDY1, IRDY2 and TRDY2. Do these pins have any significant > meaning for PCI designs? Unfortunately, I did not find any explanations > in Spartan-3E datasheet, neither in accompanying application notes. > > With best regards, > Vladimir S. Mirgorodsky >Article: 99499
My video filter breaks..... INTERNAL_ERROR:Xst:cmain.c:3068:1.158.10.1 quote: --------------------------------------------------------------------------------------------------------------- Keywords: DSP, MAC, MACC, MAD, MADD, multiply, accumulate, add Urgency: Standard General Description: XST generates an internal error in the following scenario: - A multiply accumulate (MAC) or a multiply add (MAD) is described in a hierarchical block. - This block is instantiated at least 2 times. - There are FFs on the input of the mac/multadd which are outside the instantiated block. Solution 1: To work around this problem, put the inferred registers inside of the MAC / MAD block. This issue will be fixed in ISE 8.2i. -------------------------------------------------------------------------------------- Any idea if we can expect webpack 8.2i before monday?
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