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
Use syn_useioff=0 either as a global attribute or on the port of interest. Jay wrote: > Okay, here is the answer... It was Synplify being overly helpful and > annotating the EDIF netlist! > > ---------------------------------------------------------- > Jay, > > Out of curiosity, are you using Synplify? If so, I suspect that it is > adding an IOB property to some of your flip-flops in the EDF file with > the > value of TRUE. A simple search for IOB in the EDF file will confirm > this. > > While I'm not sure how to turn it off, at least it explains why the > flip-flops are being pulled into the I/O even though you are not using > the > -pr option in Map or the IOB=TRUE attribute in the UCF/NCF file. > > Craigr > > Jay wrote: > > >>Does anyone know how to get rid of the flops in the IOBs? The mapper >>default is supposed to exclude them but low and behold, when I view >>the floor plan, I see them being used. >> >>Another question- does anyone know how to turn on the programmable >>delay on the input path of the IOB? I'm trying to solve a nasty >> > clock > >>skew problem. >> >>Thanks! >>Article: 42801
point308@hotmail.com (Mark McMahon) wrote in message news:<f30d4942.0205020128.33e302e4@posting.google.com>... > Hello all, > > I've been trying to make my own Xilinx parallel cable III using the > available schematics. My board is double sided, with a male parallel > connector so I can use any parallel cable. > > The differences between my PCB and the original xilinx one are: > (1) D6, Busy and PE are connected on the board, not at the computer > end of the cable. > (2) The tristate buffer is 74HC125A > (3) The diode are 1N4002, not 1N5817. > > I've tried two different board layouts, both of which work sometimes, > depending on which direction the wind is blowing. > I've tried both linear and switch mode power supplies. > If anyone else has successfully implemented this design I would > appreciate some pointers in the right direction. You should use a schottky like a BAT54A instead of a 1N4002. I made one and it works. It doesn't like the printer cable going thru more than one printer-switch box tho (probably need more filtering on CLK).Article: 42802
sweir wrote:
>
> Kevin,
>
> I think you have at least two options that should work:
>
> 1. Include the I/O pads in the IP core. It is then completely
> self-contained, and the OE FF's will be in the IOB with the bus FF's.
>
Okay, here is what happened.
I declared PCI33_5 I/O pads in my PCI IP core with Add I/O Buffers
option unchecked and set Pack I/O Registers into IOBs to Auto.
Some I/O ports' FFs got duplicated, but most of them didn't.
So, I set Pack I/O Registers into IOBs to True, but this time, none of
the I/O ports' FFs got duplicated.
Wasn't sure why some of them didn't get duplicated when Pack I/O
Registers into IOBs was set to True, so I added offset_out_after to a
few I/O pads with a 5ns Tco requirement.
This time, XST duplicated all the output ports' FFs, so there seems to
be something wrong with XST.
So, now I got a PCI IP core with I/O pads attached, which is not what I
totally want (The only parts I don't want are the I/O pads.), but other
than that, I am fine with it. (All IOB FFs got duplicated.)
Now, I will combine this with my backend design.
The backend design instantiates the PCI IP core, so I synthesized the
backend design, and ran NGDBUILD.
NGDBUILD complained that the backend design (top module) already
contains I/O pads, and when I saw that, I felt like, "It's over. It
didn't work . . ."
However, I just thought that if I don't add I/O pads to the backend
design which instantiates the PCI IP core, maybe things might work, so I
synthesized my backend without I/O pads, and PCI IP core got attached to
my backend without any error messages.
So, your suggestion worked, but it is not without side effects.
Since I cannot automatically add I/O pads to the backend design, I will
have to instantiate non-PCI I/O pads myself on the backend side, so I am
not totally happy with that.
Ideally, output and OE FFs of the PCI IP core should be duplicated
without I/O pads being inserted, but things don't seem to work that way,
so instead I wish I can somehow get rid of I/O pads of the PCI IP core
side after output and OE FFs get duplicated.
Is there a way to do that?
I suppose I should post a question later.
> 2. Make a source module for only the I/O portion. Using generates, it
> should be straight forward to get exactly the I/O that you want.
>
> Regards,
You mean VHDL's 'generate' statement?
I forgot to mention, but my PCI IP core is done in Verilog, and one of
the motivation of converting my PCI IP core into a netlist is to be able
to use it from a VHDL design, and also I hate to redo the entire PCI IP
core in VHDL.
Not sure how I will use generate you are talking about.
Anyhow, after instantiating PCI33_5 I/O pads in my PCI IP core,
I realized that doing so may result in multiple versions of PCI IP core
to support various PCI I/O pads of Virtex family. (PCI33_5, PCI33_3,
PCI66_3)
I decided to use generic I/O pads like IBUF or OBUFT rather than
IBUF_PCI33_5 or OBUFT_PCI33_5, so that I won't have to have multiple
versions of my PCI IP core.
MAP can convert generic I/O pads into specific I/O pads like PCI33_5
during MAP, so I did that, and the I/O pads got converted to PCI33_5.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 42803
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:<aapcfa$7ue$1@newsreader.mailgate.org>...
> Here is a problem I got in which I cannot seem to find an
> answer.
> Rather than synthesizing my PCI IP core over and over each time I make
> modifications to the backend, I will like to instantiate a netlist
> version of my PCI IP core from the backend design files to save time.
> To do so, I will declare a blackbox on the backend side, and NGDBUILD
> will automatically glue the necessary modules together.
> The problem I found was, when I synthesize my PCI IP core separately
> with "Add I/O Buffers" option of XST unchecked, XST will not duplicate
> output and OE (Output Enable) FFs for my design which is expected.
You know, this is a big problem and it's been around for many years.
It's a problem in any design where you need fast OE performance,
ZBT SRAMS, fast SDRAMs, etc. I'm surprised Xilinx hasn't fixed this
long ago, I've complained to the support hotline on two different
projects.
I think it's horrible to resort to instancing primitves, especially
if you're trying to make the design portable.
Here's how I work around the problem. I make a separately compiled
dummy module called oehack. By making an instance of oehack XST is
faked out because it doesn't know the connectivity and can't optimize
out the OE flip-flops you're trying to keep:
module oehack (
oe,
data_oe
);
input oe;
output [63:0] data_oe;
assign data_oe = { 64 {oe} };
endmodule
Article: 42804
Okay, here is a continuation of a posting I made about
duplicating IOB FFs. (See "Duplicating IOB FFs Without I/O Pads Being
Inserted in XST" for details.)
I am trying to convert a PCI IP core written in Verilog into a netlist,
so that it can be used from a VHDL design.
So far, I was able to duplicate IOB FFs of my PCI IP core only when I
let XST automatically infer I/O pads (I/O buffers) or disable automatic
I/O pad inference and instantiate I/O pads in my code.
I am going with the latter method.
Having I/O pads attached to my PCI IP core greatly complicates my
backend design because in order to avoid error messages during NGDBUILD,
I will have to disable automatic I/O pad inference of the backend design
which instantiates the PCI IP core.
Is there a way to kill or cut off the I/O pads already attached to my
PCI IP core somehow?
If I can get rid of the I/O pads attached to the PCI IP core, I can do
automatic I/O pad inference on the backend design, and that's what I
want.
Or, is there a UCF command where I can tell NDGBUILD/MAP to ignore some
of the I/O pads attached to the backend design, so that the I/O pads of
the PCI IP core are used?
I tried looking for such a command (Read the Constraints Guide.), but I
could not find one.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 42805Peter Alfke wrote: > > Rick, > I look at screw-ups as an opportunity to improve, and I will use this > unfortunate incident for that purpose. > Meanwhile, good luck with your project. > Let us know if you are still counting on the '150E part in I-grade, so we > can get you one at the earliest moment. > Peter Here are the details that I got back from my disti, Insight. It seems that they have access to a web site for pricing that is put up by Xilinx. On that web site it showed today, that BOTH the commercial and industrial temp versions of the XC2S150E are currently available with a lead time of around 4 weeks. The Insight sales person contacted her Xilinx contact and they acknowledged that it was wrong. So the problem was the data that was being displayed on the Xilinx "disti" web page. But I am still not clear about the overall process. Because when I asked for P&A on 2/28, it took until 3/20 to get an answer. A couple weeks after placing the request, I asked about status and was told that the request was "in to Xilinx" and Insight was waiting for an answer. I don't know if this means they were waiting for a direct response to the request which would imply a separate channel of information; or if they were waiting for the information to appear on the Xilinx "disti" web page. In any event, Insight is going to try to get some better pricing on the XC2S200E parts to help alleviate the price hit. I just don't think we can hold off shipping product until September. With some price cutting on the XC2S200E part we should be able to release the board to production in a timely manner. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42806
Robert Sefton wrote: > I've been through this before, but can't remember the trick. I'm trying to > simulate a full-chip Spartan 2 design with Xilinx I/O and clock buffers > instantiated in the verilog rtl. I load the "glbl" block with the design, > and drive GSR and GTS in the test bench, but I'm getting unknowns from all > of the registered I/Os and '1' from the global clock buffers. Any > suggestions would be greatly appreciated. > > Robert You must instantiate glbl.v as glbl glbl (); and assign glbl.GSR = reset; assgn glbl.GTS = 1'b0; reset signal must toggle longer than the slowest frequency period in your XC2S. UtkuArticle: 42807
In article <4eb6bec8.0204260805.5c305580@posting.google.com>, ajitoke@yahoo.com (Ajit Oke) wrote: > 2. > While configuring the device using the Boundary Scan chain, the chain > was not getting identified at all. We used the debug chain feature to > float values on the TMS, and TCK pins. We tried to detect these > voltages by a multimeter, and when the TMS pin was being monitored by > the DMM probe, the chain initialization succeeded.. We are thinking > the > capacitance of the probe helped clean the TMS logic values. > What could be the probable reason? > We have built owr own Parallel cablle III. > Thabks in advance.. > Ajit Oke > I'm obviously not the only one who has been struggling with this. I never did get my homemade PIII cable to do JTAG. However I succeeded in switching to slave serial mode, connecting my (slightly modified) PIII to the PROM socket and clocking in the bitstream with my own C program. It's also a lot faster than JTAG. Maybe I should document it but not this side of the weekend. I later obtained a shiny new PIV cable. I found that to get JTAG to work at all I put 100pF on TCK. It is very sensitive to wind direction and the type of parallel port and the impact environment variables you can tweak. So I use my own method above. JonArticle: 42808
>And not tested by the manufacturer ! Not all parameters scale the same way with >temperature. The more we add clever compensation tricks, the less obvious >becomes the behavior at elevated (or lower) temperature. Sigh. Another trick to push the envelope a bit gets harder to use. How about voltage? Is there any rule of thumb you would be willing to sign up for? Can we count on half of what we would get using the old rules? While I'm typing... It was an old Xilinx data book that explained that trick to me. Many thanks. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 42809
>Yes, I can do that if you can provide me with a TMS320C6711B that runs >from 2.5 volts. :) Might get a bit warm, but it would run real fast. :) -- These are my opinions, not necessarily my employer's. I hate spam.Article: 42810
I am looking for PDH MUX (E2,E3) VHDL and any frame (E1,T1,E2 ...) based device VHDL examples. Thanks. Dainis dainis@saftehnika.com ----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web ----- http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups NewsOne.Net prohibits users from posting spam. If this or other posts made through NewsOne.Net violate posting guidelines, email abuse@newsone.netArticle: 42811
Sounds exactly like the problems I had. I think you might use the suggestion of Steve Casselman and use schematic entry for the readback part of your circuit and instantiate it in VHDL as blackbox. This might help.. Cheers, Chris > Summary: the readback will only synthesise if driving directly to OBUFs, > not internal nets. This is driving me mad. I understand that only a > tiny percentage of users want to use readback, but surely Xilinx could > provide better support for this facility. I've read all of the > documentation they provide on readback, and am still none the wiser. -- -- Christian Plessl remove 'remove' from email-address when replyingArticle: 42812
What is a macro done with fpga-editor? How is it different from a RPM (Relationally Placed Macro) as in: http://www.riverside-machines.com/pub2/xilinx/vhdl_rpm/top.htm Bret Wade wrote: > > Hi Theorn, > > You need to be in macro editing mode in FPGA Editor, look for an .nmc extension > in the banner. If it's .ncd instead, you need to first do a "save as macro". > Once you're in macro editing mode, an external pin is added by selecting a > component pin (not just a site pin) and running the command Edit-->Add Macro > External Pin. Fill in the resulting form. You need to give the external pin the > same name as the corresponding port name for the black box in your logical > design. > > Hope this helps, > Bret > > Theron Hicks wrote: > > > I found answer 10901 and tried solution #1. I could not get it to work (I > > could not get the External Macro Pin to be available.) I looked at solution > > 2 (xapp123) but it seems to apply only to the tri-state buffer if I read the > > readme correctly. Any help? > > > > Theron Hicks wrote: > > > > > Hi, > > > My design is somewhat structural at the highest level. I would like > > > to floorplan the lower level modules and then have that floorplan (and > > > perhaps even routing) be retained at the higher level. Is that > > > possible? Is there some hidden trap that I need to be aware of (other > > > than the potential problem with the blocks not being able to be placed)? > > > > > > If this is a reasonable and wise idea, how do I do so? My code is VHDL > > > and my target device is the Spartan2E. I am currently using ISE4.1 but > > > I have ISE4.2 available. (I just haven't installed it yet, as I would > > > rather avoid changing software in mid project.) > > > > > > Thanks, > > > Theron HicksArticle: 42813
This is a multi-part message in MIME format. --------------DD10D151981A72067A965883 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Russell, The difference is that in hard macro created with FPGA Editor even the routing is locked down, allowing for predictable timing of the macro everytime. With the HDL version of an RPM only the components are locked down and the router is left to connect the components up as it sees fit, possibly changing the net delays on those routes. With a hard macro, your timing is always the same. Cheers, Stephan Russell wrote: > What is a macro done with fpga-editor? How is it different from a > RPM (Relationally Placed Macro) as in: > > http://www.riverside-machines.com/pub2/xilinx/vhdl_rpm/top.htm > > Bret Wade wrote: > > > > Hi Theorn, > > > > You need to be in macro editing mode in FPGA Editor, look for an .nmc extension > > in the banner. If it's .ncd instead, you need to first do a "save as macro". > > Once you're in macro editing mode, an external pin is added by selecting a > > component pin (not just a site pin) and running the command Edit-->Add Macro > > External Pin. Fill in the resulting form. You need to give the external pin the > > same name as the corresponding port name for the black box in your logical > > design. > > > > Hope this helps, > > Bret > > > > Theron Hicks wrote: > > > > > I found answer 10901 and tried solution #1. I could not get it to work (I > > > could not get the External Macro Pin to be available.) I looked at solution > > > 2 (xapp123) but it seems to apply only to the tri-state buffer if I read the > > > readme correctly. Any help? > > > > > > Theron Hicks wrote: > > > > > > > Hi, > > > > My design is somewhat structural at the highest level. I would like > > > > to floorplan the lower level modules and then have that floorplan (and > > > > perhaps even routing) be retained at the higher level. Is that > > > > possible? Is there some hidden trap that I need to be aware of (other > > > > than the potential problem with the blocks not being able to be placed)? > > > > > > > > If this is a reasonable and wise idea, how do I do so? My code is VHDL > > > > and my target device is the Spartan2E. I am currently using ISE4.1 but > > > > I have ISE4.2 available. (I just haven't installed it yet, as I would > > > > rather avoid changing software in mid project.) > > > > > > > > Thanks, > > > > Theron HicksArticle: 42814
Thanks to all who replied. My next question is what boards and/or manufacturers are easiest to learn with? RenArticle: 42815
Hi,
I still need to get an answer to my original concern. I am
considering using the LVPECL capability of the Spartan2E to distribute a
clock signal at 102.4 MHz. The system consists of up to 34 boards.
Board 1 is a clock generator, board 2 sets sytem timing, and board 3
thru 34 are counter/timer boards. Board 1 buffers the clock and
provides outputs to drive the other 33 board clock inputs. In the
current system board 1 is all LVPECL and the other boards use a
SpartanXL with an external LVPECL to LVTTL conversion for the clock.
(Clock is 204.8 MHz). In the new system I was considering using a
Spartan2E on the new board for the LVPECL outputs (and clock de-skewing)
and a Spartan2E on the other boards for the LVPECL input and the
clockDLL. After the last discussion, I am wondering if I should dump
the LVPECL clock distribution altogether and use LVCMOS or etc.
Thanks,
Theron
Article: 42816Ren, > My next question is what boards and/or manufacturers are easiest to learn with? when looking for an FPGA development board, consider the following issues: * Tools: The tools for design entry, synthesis, implementation and simulation should be freely available, as tools are expensive. This narrows your choice of boards a lot. I would look for a board with a Xilinx Spartan-II or Spartan-II-E FPGA, as these may be programmed with the free Xilinx WebPACK software. * Complexity: The FPGA on the board should have a reasonable complexity, so that you can implement a few things without being forced to count gates and optimize too much during development. Having some unused resources even helps during debugging, as you can implement embedded logic analyzers and so forth. In terms of "marketing gates" (as Xilinx and Altera use in their data sheets) I would look for at least 100-k gates, which will be enough for a complete system-on-chip with CPU, memory, and some additional some logic. * Peripherals: The board should have enough peripherals for you to start working. Basically this is a few buttons, LEDs, a display, RAM. However, peripherals require I/O pins, board space and cost some money, which increases the cost of the system and may decrease your expansion possibilities. For this reason, I would avoid buying too much peripherals that I do not require. * Expansion: Sooner or later, you will want to attach your own circuitry to the board. To do so, you need spare I/O pins. On some boards, there are no spare pins, instead everything is multiplexed somehow, which may create a lot of headaches. I hope this helps you develop some criteria to select your board. We offer two boards as well, please refer to: http://www.trenz-electronic.de/prod/proden6.htm BTW, we have some tutorials as well, have a look at: http://www.trenz-electronic.de/down/tc-XC2S-SoC-1.pdf http://www.trenz-electronic.de/down/tc-XC2S-SoC-2.pdf Best regards Felix _____ Dipl.-Ing. Felix Bertram Trenz Electronic GmbH Brendel 20 D - 32257 Buende Tel.: +49 (0) 5223 4939755 Fax.: +49 (0) 5223 48945 Mailto:f.bertram@trenz-electronic.de http://www.trenz-electronic.deArticle: 42817
Hal Murray wrote: > > >Yes, I can do that if you can provide me with a TMS320C6711B that runs > >from 2.5 volts. :) > > Might get a bit warm, but it would run real fast. :) I am discussing a spec problem with TI on the C6711B. Seems that they spec'd the C6711 with a shorter hold time (although they lengthened it a bit in the errata). The C6711B has a 2.5 nS hold time which is 1 nS longer than the SBSRAM. But he also explained that "the device returned to its standard operating voltage of 1.8V". So they must have been spec'ing it at something higher although I can't find it. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 42818
Jim, The QFP package for Spartan II is something I have not looked into. Two adjacent outputs will be +/- 25 ps difference in their runs (as we design the packages to have low skew between + and - of a 'differential' pair), even in the worst packages, so it is pretty much up to the PCB layout designer to not add any gross skew between the +/- pair. Austin Jim Granville wrote: > Austin Lesea wrote: > > > > Jim, > > > > Package skew is +/- 25 to 125 ps, depending on the lengths of the runs from the pads to the pcb > > balls, and to the resistors. > > > > For test boards, we keep the skew of external differential pairs to less than +/- 2.5 ps, and the > > differential pairs are constructed to be 100 ohms differential, side by side, with an approximate 65 > > to 68 ohm impedance from a single rail to ground. > > > > The actual drive delay difference from one IOB to the next IOB is less than +/- 20 ps (using the > > clock tree to adjacent IOB FFs) in this family of parts. > > So, given that balanced drive would be placed by the designer on > adjacent IOB, > does that need an additional package adder, or not ? > > QFP packages would by nature, give better delay-balance than BGA ? > > -jgArticle: 42819
Another question? If I am using the lvcmos18 I/O standard can (should) I use the same plane and regulator for both power busses?Article: 42820
Answered my own question... I cant use the LVCMOS18 because I am using some pins in the configuration area as well. Serial configuration prom requires VCCO = 3.3 volts. Theron Hicks wrote: > Another question? If I am using the lvcmos18 I/O standard can (should) I > use the same plane and regulator for both power busses?Article: 42821
"rickman" <spamgoeshere4@yahoo.com> schrieb im Newsbeitrag news:3CD18376.27E67147@yahoo.com... > Exactly how does this help if the commercial temp chips are not > available? If you really need the final ICs now (for shipping) then it will not help. But if you "just" need ICs for prototypes, it will. -- MfG FalkArticle: 42822
Have a look at our tutorials at http://www.al-williams.com/pictutor. Somewhat under construction, but mostly there. The Xilinx board mentioned there are here and we are just qualifing them before we ship them (probably next week). This batch is already half gone. Al Williams AWCArticle: 42823
Hi Noddy, I think my solution maybe wont work for you because your reference and output frequencies are too high. Anyway. I will try to describe it. In my application the reference signal is between 5 kHz and 50 kHz. A counter running at a very high frequency is used to measure the number of Systemclock cycles between the edges of the reference signal (Reference Period). I constructed an entity that takes the Systemclock and the actual Period value as input and produces an output clock (I call it FineClock) with a frequency of ReferenceFreq * 2**n. The FineClock feeds an Akkumulator. It adds a constant at every SystemClock cycle. The highest bit of the akkumulator is the output frequency. The Akkumulator constant defines the relation between the reference frequency and the final output frequency. For this design it is very important that there are no "dead" SystemClock cycles. For ex. the SCLK edge that latches the period value must also count for the next period measurement. Otherwise the error adds up and the whole thing will not "lock". I have used this type of PLL in many designs for different customers and I am really very pleased with the results. If you want to contact me, use "mkraus" instead of "newsreply" in the Email address below. - Manfred Kraus ---------------------------------------------------------------------------- ---------------- CESYS Gesellschaft für angewandte Mikroelektronik mbH Buchenstr. 13 D-91074 Herzogenaurach Tel. +49 9132 733 400 Fax. +49 9132 733 401 Email: newsreply@cesys.com URL: http://www.cesys.com ---------------------------------------------------------------------------- ---------------- "Noddy" <g9731642@campus.ru.ac.za> schrieb im Newsbeitrag news:1020370492.898003@turtle.ru.ac.za... > Hi Manfred, > > My output frequency range is very small... between about 31.5MHz and > 32.5Mhz, although I need mHz precision. It should use a 5MHz reference > signal. > > Adrian > > > Hi Adrian, > > I developed a digital PLL some years ago > > and found some unknown tricks. > > Maybe I can help you. > > What is your desired output frequency range ? > > > > -Manfred > > > > > > > > "Noddy" <g9731642@campus.ru.ac.za> schrieb im Newsbeitrag > > news:1019660268.49750@turtle.ru.ac.za... > > > Hi, > > > > > > I am trying to design a high precision (30 bit) frequency synthesiser > > inside > > > a Spartan II. Of course, normal way to do this is with a charge pump, > > > voltage controlled oscillator and a phase lock loop. > > > > > > Can anyone point me to some good references? I have a very high > precision > > > 5Mhz which is generated from a hydrogen maser and will be used as the > > input > > > clock signal. > > > > > > thanks > > > adrian > > > > > > > > > > > > > > >Article: 42824
It seems that all free DDR SDRAM controller sources for Virtex-II are buggy, not completed or not available (any more) XAPP253 for example is buggy and not available. Any suggestions where I can buy a netlist (or source code) that is available now and usable ? Any idea what the costs could be ? Any experience with the Insight controller ? Thx vm -Manfred
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