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
Il 25/08/2008 21.08, Jon Elson ha scritto:
> Somebody asked, "Gee, couldn't you do that with an FPGA?" Well, a few
> years ago, maybe not. So, could anyone suggest some fast FPGAs that can
> handle clocks in the 500+ MHz range? I normally work with Xilinx, but
I agree the SERDES solution is more elegant and powerful.
But, just for a comparison of what can be done with cheap parts...
In the summer I had some spare time... just for fun, I (almost) did a
simple logic analyzer using a Spartan3E500, -4 (slower), using a Nexys2
board. A 32 channel, 400 Mhz, 16 Mbytes buffer, RLE compressed, high
speed USB 2.0 logic analizer at $99. Not bad!
Never had time to do the PC software part and finish some pieces...
maybe next holidays if it's raining...
Using the tecnique shown in XAPP225 (4 "parallel" phase shifted
acquisition, and combinatorial stage to "find" the edge), the design can
easily reach 400 Mhz sampling (100 Mhz clock, 4 phases) on each of 32
input channels. I didn't even try to manually floorplan anything, it was
more than enough for me. Besides, it's for fun!
A single acquisition module uses a 100 Mhz clock and a 90° copy.
For each input channel, you get 4 bits in parallel in output, with the 4
last samples at 400 Mhz effective sampling frequency.
There's still space for RLE compression, triggering unit, external ram
controller, USB slave fifo interface, and a bunch of internal I2C
registers. Should be no problem fitting "just" a delay line made with
counters.
With the last 4 samples available "in parallel" at a much slower clock
(100 Mhz), you can use a mux to "choose" the phase delay you want with
the two least significant bits of the choosen delay.
From there on, it's easy since frequencies are "normal".
How to *output* those.... ehm...
Here is the front-end code (sorry for comments in italian):
`timescale 1ns / 1ps
/*
Cfr. XAPP225.
*/
module sampler_4x #(parameter integer WIDTH = 32)
(
input [WIDTH-1:0] din,
input clk,
input clk_90,
// output
output [(4*WIDTH)-1:0] q
);
wire [WIDTH-1:0] az0, az1, az2;
wire [WIDTH-1:0] bz0, bz1, bz2;
wire [WIDTH-1:0] cz0, cz1, cz2;
wire [WIDTH-1:0] dz0, dz1, dz2;
// sequenze di FF organizzati in modo tale da non aver mai campionamenti
piu' vicini di 0.75*Tclk
// FD: DFF synchronous reset
// FD_1: DFF with Negative-Edge Clock and Synchronous Reset
genvar i;
generate
for (i = 0; i < WIDTH; i = i +1)
begin: gen_ifddr
// fase 0
FD ff_az0(.D(din[i]), .C(clk), .Q(az0[i]));
FD ff_az1(.D(az0[i]), .C(clk), .Q(az1[i]));
FD ff_az2(.D(az1[i]), .C(clk), .Q(az2[i]));
FD ff_az3(.D(az2[i]), .C(clk), .Q(q[i]));
// fase 90
FD ff_bz0(.D(din[i]), .C(clk_90), .Q(bz0[i])); // 0.75T
FD ff_bz1(.D(bz0[i]), .C(clk), .Q(bz1[i]));
FD ff_bz2(.D(bz1[i]), .C(clk), .Q(bz2[i]));
FD ff_bz3(.D(bz2[i]), .C(clk), .Q(q[WIDTH + i]));
// fase 180
FD_1 ff_cz0(.D(din[i]), .C(clk), .Q(cz0[i])); // 0.75T
FD ff_cz1(.D(cz0[i]), .C(clk_90), .Q(cz1[i])); // 0.75T
FD ff_cz2(.D(cz1[i]), .C(clk), .Q(cz2[i]));
FD ff_cz3(.D(cz2[i]), .C(clk), .Q(q[2*WIDTH + i]));
// fase 270
FD_1 ff_dz0(.D(din[i]), .C(clk_90), .Q(dz0[i])); // 0.75T
FD_1 ff_dz1(.D(dz0[i]), .C(clk), .Q(dz1[i])); // 0.75T
FD ff_dz2(.D(dz1[i]), .C(clk_90), .Q(dz2[i])); // 0.75T
FD ff_dz3(.D(dz2[i]), .C(clk), .Q(q[3*WIDTH + i]));
end
endgenerate
endmodule
Article: 134751On 28 Aug., 12:37, David Brown <da...@westcontrol.removethisbit.com> wrote: > The LGPL is a little lighter - it allows you to link the LGPL'ed code > with non-GPL'ed code as long as anyone with the binary is able to get > the source code to the LGPL part, modify it, re-link it, and use the new > version. =A0This is fine for things like dynamically linked libraries on = a > desktop OS (that's what it was designed for), but hardly practical for > FPGA IP! Why not? There is no need to be able to do this dynamically. If you can do it with the usual FPGA toolflow everything is in order. In the software world there has been a long discussion about what linking means. For the hardware world this is completely in the open. When using GPLed IP, must other FPGA IP in the same project be under GPL? (Very likely.) But how about the board layout? (Maybe) How about software running on a GPLed processor (following the dynamic linking debate this probably is a yes for software stored in the bitstream and a no for software loaded later). I think that anyone who uses a software license for hardware should clarify what this means when applied to hardware. Just write an appendix to the license. After all the creator of the work is free to license under any terms he likes, he is not bound by the FSFs view of the world. And yes, if you want to use it together with EDK, the LGPL is the better starting point than the GPL.Article: 134752
Jon Elson wrote: > Well, given the serdes function of the Virtex, maybe we can go 1 ns > input and output resolution, with only 125 MHz clock on the > counter/comparator. My boss would really love that. The smaller Virtex > seem to come in a 1mm-pitch BGA, maybe I can even learn how to do that > myself. Since the balls are only around the perimiter, it might be > visibly inspectable. I'll have to do more research to find out what is > practical. You could add some pin-redundancy as this seem to have a (relatively) low number of inputs ? -jgArticle: 134753
On 28 Aug., 18:24, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > > If MicroBlaze was a hard-core, then maybe I'd agree. However, as a > > soft-core, to me, it's the same as linking with a library. > > If that were so, Genode would be required to GPL Microblaze, and our > troubles would already be solved. We would just refer everyone else to > Genode for the Microblaze code. No. GPL prohibits linking with non GPL code, that is a fact. Compiling an FPGA bitstream that contains both Genode and non GPL Xilinx Cores is therefore a violation of Genodes GPL license. This does not mean that the Xilinx Cores suddenly fall under the GPL. It only means that the creators of Genode do not allow you to create such a bitstream. (Violators face multiple years in prison in most countries.) Norman writes that this is not what he intended, so he probably should change the license. As I interpret the LPGL it provides exactly the desired effects: Modifications to Genode must be made publicly available, but all other cores in the system can have any license including the Vendor license. Kolja SulimmaArticle: 134754
Jon Elson wrote: > Jim Granville wrote: >> >> Analog is a candidate, but the OP mentioned a 100:1 dynamic range. >> Maybe some range-sw caps ? >> > Well, it is all designed and the board is layed out. I used the AD > CMP603 single fast comparator. A bear to mount, but a very fine chip > for the purpose. It DOES use 2 range switching caps, plus stray > capacitance as the lowest cap value, plus 2 selections of > current-programming resistor. > > THEN, my boss said -- "Hey, couldn't you do that with an FPGA?" One nice feature of Analog-retrigger, is the lack of sampling jitter. A minus is the calibration and drifts How important is jitter ? Another hybrid analog approach is to use multiple Gateable Osc, and Dividers. The Osc is DAC controlled over just over 2:1 in Freq, and the divider takes care of the rest. This is also easy to calibrate, as you can flip from monostable to re-trigger, and use a longer timebase to get fractional ns values. What is the smallest setting, and desired Step Size ? >> Anyone seen Vos vs Common Mode voltage plots for LVDS channels >> in FPGAs ? Cross talk figures ? > > I guess you could measure it yourself. Would take a while to get cross talk numbers :) -jgArticle: 134755
Currently I have a design that processes video data with a number of adjustable parameters (like window borders) and process results (like pixel counters). I seen to have about 28 of them so far, ranging from binary on/off to 10 bit BCD counters. These are displayed on a VGA port or an NTSC overlay. All these parameters exist on the fabric and are Muxed into a overlay module that displays them in real time. My question is how many of these parameters and counters can I add before I run into some real serious routing issues? Is there anything I can do to minimize this potential problem? Brad Smallridge AiVisionArticle: 134756
bamboutcha9999@hotmail.com wrote: > On 27 août, 18:29, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: >> bamboutcha9...@hotmail.com wrote: >>> Hello ! >>> I would like to know the frequency used by Xilinx (Virtex 5) to >>> decrypt bitstream before configuration . >>> The decrypter is it slow with small area ? fast with big area ? >>> unfortunately it's not documented by xilinx . >>> Thank u for help >> It decrypts at the same rate as the configuration clock. This could be >> anywhere from KHz to the maximum of 100 MHz as specified in the data sheet. >> >> Ed McGettigan >> -- >> Xilinx Inc. > > > Ed , > thank for you answer . > The rate of config clk is fixed by the user ( from 2Mhz to 60Mhz ) so > i did not understand by "anywhere from KHz to the maximum of 100 > MHz" , 2 MHz to 60 MHz falls within the window that I stated of KHz to 100 MHz. > moreover with my > encrypted bitstream (Eprom => FPGA) i couldn't run over 42 Mhz . > why ? Likely because of the timing relationships created by the EPROM. You should review the data sheet for the EPROM to verify the maximum frequency of operation in the mode that you are using it. > What i want to know is the throughput of the decrypter (AES 256 CBC) , > how many cycles takes this architecture used by Xilinx ? The decrypter input-to-output is 1:1, so there are no stalls required for the input bitstream. I don't know what the latency is of the actual block as it has no impact on the configuration sequence. > is it Safe > at 100% against attacks ( timing , fault attack , side channel > attack ....) ? Austin Lesea has said once or twice in this newsgroup that the NSA has approved it as secure and we know of no one that has broken it. Ed McGettigan -- Xilinx Inc.Article: 134757
found in other group: http://www.eetimes.com/showArticle.jhtml?articleID=210201176&cid=NL_eet http://www.patentstorm.us/patents/7391237/description.html -LasseArticle: 134758
Kolja Sulimma <ksulimma@googlemail.com> writes: > No. GPL prohibits linking with non GPL code, that is a fact. Compiling > an > FPGA bitstream that contains both Genode and non GPL Xilinx Cores is > therefore a violation of Genodes GPL license. Only if the resulting bitstream is distributed. You can do it in the privacy of your own home all you want.Article: 134759
langwadt@fonz.dk wrote: > found in other group: > > http://www.eetimes.com/showArticle.jhtml?articleID=210201176&cid=NL_eet > > http://www.patentstorm.us/patents/7391237/description.html > > -Lasse Patents often clearly fail many of the thresholds they are supposed to pass, in part because the filing lawyers are motivated by the payment and act of creating a patent. It is not helped either, that most lawyers have no idea, or experience, of the item-field. A patent is merely a license to litigate, -jgArticle: 134760
Dear Eilert, Thanks very much for reply. I just saw reply today. . On Aug 14, 2:36=A0am, backhus <n...@nirgends.xyz> wrote: > Hi Nirav, > you said your focus is on high speed data transfer. > How about the EFM-01 Board fromwww.cesys.de/index_en.html > > The easyfpga-board has a maximum transfer rate of 8 Mbit (FTDI to FPGA) > because it's just anusbto RS232 converter. (Sufficient?) > > Cesys and opalkelly both use the Cypress FX2 chip which provides a > parallel bus interface to the FPGA with nearly full USB2 transfer rate. > > Now you have to compare how the vendors support the FX2 interface and > the software development on the host side. And of course what size of > FPGA you need (500Kgates vs 4000KGates+SDRAM), which depends on the > application you have in mind. > > Have a nice synthesis > =A0 =A0Eilert > > Nirav schrieb: > > > I am looking for a development board withUSBInterface for hardware- > > in-loop. > > I don't think I want to mess withUSB. > > I just want to use some easy to use board which will allow me to > > transfer data (at high speed) to-fro the board. > > > I saw board fromwww.easyfpga.com > > andwww.opalkelly.com > > > But I wasn't sure.. > > Anyone has soem first hand experience with these boards? > > How good are they for new-bie? > > > Any recommendations?Article: 134761
Il 28/08/2008 22.00, Antonio Pasini ha scritto: > // fase 180 > FD_1 ff_cz0(.D(din[i]), .C(clk), .Q(cz0[i])); // 0.75T > FD ff_cz1(.D(cz0[i]), .C(clk_90), .Q(cz1[i])); // 0.75T > FD ff_cz2(.D(cz1[i]), .C(clk), .Q(cz2[i])); > FD ff_cz3(.D(cz2[i]), .C(clk), .Q(q[2*WIDTH + i])); Argh! I stand corrected... I don't remember exactly what I was drinking last summer when I wrote this :-), but it's just plain wrong! At 180 and 270 degrees obviously one should use inverted clocks or properly phase shifted clocks... and then arrange the later stages.. The XAPP225 trick still apply... basically, "distributing" the total period budget among a pipeline of four or more FF, to finally align the data to the same 1/4 clock. I "improved" the design starting from the back, and came backwards trying not to have more than 0.75T between FF... wonderful, but wrong. The line between cleverness and stupidity is so thin :-) It's amazing how it's easy to find errors when you try to explain your work to others!Article: 134762
Brad Smallridge wrote: > Currently I have a design that processes > video data with a number of adjustable > parameters (like window borders) and > process results (like pixel counters). > I seen to have about 28 of them so far, > ranging from binary on/off to 10 bit BCD > counters. > These are displayed on a VGA port or an > NTSC overlay. All these parameters exist > on the fabric and are Muxed into a overlay > module that displays them in real time. > > My question is how many of these parameters > and counters can I add before I run into > some real serious routing issues? Is there > anything I can do to minimize this potential > problem? > > Brad Smallridge > AiVision Since modern FPGAs are significantly routing resources, I'd suggest you won't run into a routing problem. Have you seen something that suggests you'll have a problem? Consider that the mux can be implemented as a binary tree with 2-input muxes (or 4-input for some families). A binary tree is much simpler to implement and distribute than a priority encoder style of multiplexer (using cascade logic). If your timing is ample, the binary tree is great. If you need better timing, coding to force more than one level of priority encoder style mux (10:1 mux structures, for instance) can provide a good balance between more, longer lines and speed. I seriously think that if you don't concern yourself with it, it won't be an issue. Unless timing is a problem. Even then, pipelining of the large mux will help as well. There are too many ways to make it work cleanly. Just my humble opinion, - John_HArticle: 134763
On Aug 28, 3:47=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > Currently I have a design that processes > video data with a number of adjustable > parameters (like window borders) and > process results (like pixel counters). > I seen to have about 28 of them so far, > ranging from binary on/off to 10 bit BCD > counters. > These are displayed on a VGA port or an > NTSC overlay. All these parameters exist > on the fabric and are Muxed into a overlay > module that displays them in real time. > > My question is how many of these parameters > and counters can I add before I run into > some real serious routing issues? Is there > anything I can do to minimize this potential > problem? > > Brad Smallridge > AiVision You might think of using a BlockRAM as a big multiplexer. You can use one port to enter variable data, and the other port to output them for display. Speed will not be an issue. Just a thought.... Peter Alfke, from homeArticle: 134764
Jon Beniston wrote: >> The GPL says (roughly) that any code that is directly linked to the >> GPL'ed code must also be GPL'ed. You can't use GPL'ed IP and non-GPL'ed >> IP in the same FPGA. > > Ok, I think we agree here. > >> The LGPL is a little lighter - it allows you to link the LGPL'ed code >> with non-GPL'ed code as long as anyone with the binary is able to get >> the source code to the LGPL part, modify it, re-link it, and use the new >> version. This is fine for things like dynamically linked libraries on a >> desktop OS (that's what it was designed for), but hardly practical for >> FPGA IP! > > You don't have to supply the modified code with the FPGA though. I'm > sure a web download would be suitable. > Technically, according to the letter of the GPL 2, a web download alone is not enough (it was considered too unreliable at the time the GPL2 was written), but the GPL 3 allows it. It's a minor quibble, of course. But what is important for using the LGPL is that the user (or anyone who legally acquires the binary) must have access to everything they need to modify the LGPL'ed code and produce a new binary, or exactly the same binary as the original. In the software world, this means that the rest of the program must be available as a linkable object - easy if you have an OS and the LGPL'ed code is a dynamic library. It must also be possible for the user to download their binary into the system. It's okay if the tools to do this cost money, as long as the user is free to buy them - I don't think you'd have to provide any Microblaize IP, as that's a standard library with the tools. But you'd have to include compiled versions of all your own IP, possibly also third party IP, and things like pin layout files. And if the bitstream is to be encrypted, you have a new set of issues... All in all, the LGPL is very impractical for embedded systems. >> A better choice of license would be what is known as a "modified GPL" or >> "GPL with exception" license (or the very similar Mozilla Public >> License). Here the GPL is explicitly modified to apply only to the >> source files provided > > What happens if someone modifies a file to use a function that is in a > new file though? Do they have to provide this? > I don't think so - there is no requirement that your modified m-GPL'ed code can work without the rest of your system. The aim is to codify the idea that the package you got under the m-GPL is a community effort - you can use it as you want, but can't claim you wrote it, and if you extend or improve it, these changes must be available to others. It has always struck me as a very fair license giving the best of both worlds (it can be used freely even in commercial systems, but enforces more "freeness" than BSD-style licenses).Article: 134765
Arithos Designs is starting a new weekend batch on "Fundamentals of Digital Signal Processing" and "Fundamentals of Digital Image Processing" and "Front end VLSI design and simulation" from 6th September. For rough outline of the course, please check in our website. The duration of the Course runs for a month. It is an good opportunity for the people in industry to freshup their basics and upgrade their skillset. Also for the students to get prepared for their dream jobs and build up their confidence level. Anyone who are intrested to take up the course please send an confirmation email or call at our office for furthur enquiries or drop an email for furthur enquiry @ veena@arithos.com. **Course completion certificate, and job assistance will be provided at the end of the training. **Projects for Btech/Mtech final year students are also provided. Also we request you to join the Arithos Designs community at Orkut. Regards, Arithos Designs www.arithos.com A Premier DSP Design Consultancy and Corporate Training Company.Article: 134766
Kolja Sulimma wrote: > On 28 Aug., 12:37, David Brown <da...@westcontrol.removethisbit.com> > wrote: > >> The LGPL is a little lighter - it allows you to link the LGPL'ed >> code with non-GPL'ed code as long as anyone with the binary is able >> to get the source code to the LGPL part, modify it, re-link it, and >> use the new version. This is fine for things like dynamically >> linked libraries on a desktop OS (that's what it was designed for), >> but hardly practical for FPGA IP! > > Why not? There is no need to be able to do this dynamically. If you > can do it with the usual FPGA toolflow everything is in order. > > In the software world there has been a long discussion about what > linking means. For the hardware world this is completely in the open. > When using GPLed IP, must other FPGA IP in the same project be under > GPL? (Very likely.) But how about the board layout? (Maybe) How about > software running on a GPLed processor (following the dynamic linking > debate this probably is a yes for software stored in the bitstream > and a no for software loaded later). > > I think that anyone who uses a software license for hardware should > clarify what this means when applied to hardware. Just write an > appendix to the license. After all the creator of the work is free to > license under any terms he likes, he is not bound by the FSFs view of > the world. > This is very important - publishers should always give a statement of the aim or "spirit" of their license, as well as the legal stuff. Sometimes these are contradictory (I've seen software given out with the GPL "so that anyone can use it in their code"), but mostly it helps. In particular, especially in the FPGA field, a clear indication of what the author means by "linking" and "derivative works" is vital. > And yes, if you want to use it together with EDK, the LGPL is the > better starting point than the GPL. > As you say, there have been plenty of discussions and debates around linking and derivative works regarding the GPL/LGPL, and there are plenty of opinions when it comes to the grey areas (such as binary modules in the Linux kernel) and use outside "ordinary" software (such as for FPGA IP). The LGPL is certainly a better starting point than the GPL - but it is still not a good choice of license. With a clear enough statement of the intent of the license, it might be okay - but otherwise it's better to pick a license that is clearer to start with. Of course, the author is free to pick whatever license they want. In this particular case, the author has chosen a dual license - GPL (which basically allows free academic, testing and evaluation usage), and a commercial license with no issues about linking or distribution.Article: 134767
langwadt@fonz.dk wrote: > found in other group: > > http://www.eetimes.com/showArticle.jhtml?articleID=210201176&cid=NL_eet > > http://www.patentstorm.us/patents/7391237/description.html > That is almost an exact description of the system used on Altera's NIOS development kits - and probably thousands of other designs.Article: 134768
On Aug 29, 2:09 am, Peter Alfke <al...@sbcglobal.net> wrote: > On Aug 28, 3:47 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> > wrote: > > > > > Currently I have a design that processes > > video data with a number of adjustable > > parameters (like window borders) and > > process results (like pixel counters). > > I seen to have about 28 of them so far, > > ranging from binary on/off to 10 bit BCD > > counters. > > These are displayed on a VGA port or an > > NTSC overlay. All these parameters exist > > on the fabric and are Muxed into a overlay > > module that displays them in real time. > > > My question is how many of these parameters > > and counters can I add before I run into > > some real serious routing issues? Is there > > anything I can do to minimize this potential > > problem? > > > Brad Smallridge > > AiVision > > You might think of using a BlockRAM as a big multiplexer. > You can use one port to enter variable data, and the other port to > output them for display. > Speed will not be an issue. > Just a thought.... > Peter Alfke, from home I typically use block or distributed RAM for such muxes. Many of my designs contain parameters set by I2C bus (very slow). I use RAM as the readback port for all read/write registers / bits. For other read-only bits there is a mux in the fabric. So now you have a mux with many fewer inputs, specifically adding more parameters to the mix makes no impact on the mux size. Obviously adding more dynamic inputs like counters will increase the mux unless those are slow enough to add to the RAM instead. Regards, GaborArticle: 134769
Hi everyone, I have a PA3 device on a board where I want to make a quick blank check to decide if it's neccesary to program or not to program. I use a JTAG system from Goepel that uses SVF files generated by Actel. The guy who designed the FPGA can't get me a 'blank check' SVF or a shortened verify. What I try now is to delete as much as possible from the verify SVF I have to keep the time short but I'm a bit lost how to do the manipulations right. My idea is to use just 1-5 of the 2300 rows for the verify the fpga has. Any ideas? Thanks, JohannesArticle: 134770
On Aug 28, 3:11 pm, John_H <newsgr...@johnhandwork.com> wrote: > On Aug 28, 8:30 am, rickman <gnu...@gmail.com> wrote: > > > > > You don't have to use Virtex to get SERDES. The low cost Lattice > > family has SERDES and should be able to do what you are looking for at > > a *much* lower price. > > While it's true the 3+Gb/s high speed serial channels are available in > the Lattice parts (my first Lattice design has started in the ECP2M - > yay!) the SERDES referred to in the Virtex parts for these posts are - > unless I'm sincerely mistaken - the serializer/deserializer elements > built into the general IOBs. The standard I/Os end up with 800Mb/ > s-1Gb/s data rates (pulling these numbers from memory) with a simpler > interface than the MGTs or similar RocketIO that can far exceed the > general I/O data rates. > > Even in the lattice part, 32 channels of receive and 32 channels of > transmit is costly in the 3Gb/s SERDES channels. > > - John_H While the Lattice ECP does not have the SERDES blocks in the I/O, you can run fairly high data rates with their DDR input flops using the IDDRX2B "2x geared" primitive. Only the edge clock has to run at 1/2 the bit rate (DDR) and the internal clock runs at 1/2 of that speed (1/4 the bit rate) getting 4 bits on every rising edge. You can see this in the 7:1 serdes reference design (I use this for Channel-Link at 85 MHz = 595 Mbps). I should also add that I use LVDS for these data rates. Regards, GaborArticle: 134771
On 29 aug, 15:37, johannes.jan...@gmx.de wrote: > Hi everyone, > I have a PA3 device on a board where I want to make a quick blank > check to decide if it's neccesary to program or not to program. I use > a JTAG system from Goepel that uses SVF files generated by Actel. The > guy who designed the FPGA can't get me a 'blank check' SVF or a > shortened verify. > What I try now is to delete as much as possible from the verify SVF I > have to keep the time short but I'm a bit lost how to do the > manipulations right. My idea is to use just 1-5 of the 2300 rows for > the verify the fpga has. > Any ideas? > Thanks, > Johannes use USERCODE and verify only that AnttiArticle: 134772
On Aug 29, 2:58 pm, MooseFET <kensm...@rahul.net> wrote: > On Aug 28, 9:50 pm, already5cho...@yahoo.com wrote: > > > > > On Aug 28, 3:58 pm, MooseFET <kensm...@rahul.net> wrote: > > > > On Aug 27, 11:11 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > > > > > MooseFET wrote: > > > > > On Aug 27, 1:16 pm, Kim Enkovaara <kim.enkova...@iki.fi> wrote: > > > > >> Even with FPGAs the code can be quite portable. Usually quite small > > > > >>... > > > > > I have never seen a case of FPGA code going between Xilinx's tools and > > > > > Altera's without some very serious rewriting. > > > > > Then you have something wrong in your coding style. Normally if some > > > > portability is taken into consideration during design, porting takes > > > > few days to get first impressions. > > > > I wasn't referring to just my code when I said "seen". > > > > Do you use the assignment of the "Z" value to cause a tri-state? > > > Quartus doesn't compile them. > > > When you assign "Z" to external pin - Quartus compiles it very well, > > thank you. > > Have you done it? Of course. > I am surprised if they have fixed it. I had to > recode to use the tri() to get the tri-state pins to work. I had > defined a component with the tristate pins that I connected directly > to the pins of the chip. The compiler would choke on it. The same > code compiled on Cypress's "warp" and produced exactly the tristated > pin I expected. > Did your component had tristate pins defined as out or inout? The later, indeed, had problems until relatively recently but the former always worked as expected. I, personally, always prefer to have separate in and out ports in internal components, so I wasn't hit by earlier bugs. Why they fixed it at the end? I think, the main reason was SOPC builder. They wanted the same SOPC builder output to work both as a top level project and as a component so they had little choise. Hopefully, by now, they realized that except for the toy problems no sane developer will use SOPC builder output as a top level but the inout fix is done already and there are no reason to go back. > > On the other hand, internal tristate nodes are not supported by Altera > > architecture - how would you expect Quartus to synthesize them in this > > case? Infer muxes? > > I didn't do this but yes a compiler could easily turn it into > something like this to send to the fitter: > > Y = X1 & EN1 # X2 & EN2 # X3 & EN3; > > There is no need to make a full mux because there should only be one > assignment of a non-Z value at a time and thus only one EN# would be > true. As I said in another post, nobody here codes this way so I have no idea whether the compiler does the right thing. P.S. I added comp.arch.fpga to the list. Let's see the opinion of real experts.Article: 134773
Gabor wrote: > > While the Lattice ECP does not have the SERDES blocks in the I/O, > you can run fairly high data rates with their DDR input flops using > the IDDRX2B "2x geared" primitive. Only the edge clock has to > run at 1/2 the bit rate (DDR) and the internal clock runs at 1/2 > of that speed (1/4 the bit rate) getting 4 bits on every rising edge. > > You can see this in the 7:1 serdes reference design (I use this > for Channel-Link at 85 MHz = 595 Mbps). I should also add > that I use LVDS for these data rates. > > Regards, > Gabor Thanks for that info! I managed to miss that capability when I went through the data sheet. It may be time for me to reread the info on the part I'm now designing with: an ECP2M. The Lattice I/Os (faster speed grade, of course) are rated at 840 Mb/s which would need a clock of only 210 MHz for the IDDR2XB which should be quite capable in those devices. The ECP2 family even has 144 pin tqfp and 208 pin pqfp packages. That would really be a superb device for this problem. - John_HArticle: 134774
On Aug 26, 5:17=A0pm, "MM" <mb...@yahoo.com> wrote: > "Sepideh Miller" <bagh...@gmail.com> wrote > > > > > How can I tell if I have the EDK? > > Type xps in Start/Run and click OK. See waht happens... > > /Mikhail Thanks!
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