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
I solved the problem by instantiating both designs, and run them alongside in a new top module, but I will remember that there are other ways to compare waveform results. When I was reading ModelSim's User Guide, I believe I read a section that mentioned about VCD, but didn't want to spend a lot of time learning more things because I wanted to quickly compare results. I know not willing to learn new design approaches is fatal in engineering, but for the time being, I wanted to compare waveform results quickly because I am still at the the implementation stage of a design, and not at the verification stage of a design yet. Yes, when I reach the verification stage of my design, I will definitely try to learn new verification methods, so that I can test my design effectively. Although I am sure some people don't like my "quick fix" type of approach to testing. Thanks, Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.) Steve Meyer wrote: > > One way to do the comparing is to add the P1364 standard dumpvars > feature by adding call "$dumpvars" to the design source (preferably at time > 0 or if you do not want to compare results until a given time, at the at > that time). The first simulation will write verilog.dump file. After > simulation runs, copy file to other name and run model to compare again > with added $dumpvars. Then just use diff command to compare results. > It turns out that a given simulator will produce identical dumpvars file > providing wire declarations in two designs are same. This does not help > much in isolating differences. If you want to compare results from > different related designs or two different simulators, you need simple > program to compare dumpvars files. You can purchase fancy ones or you > can write one quite easily yourself. > > Another standard P1364 approach is to use vpi_ and add value change call backs > (vpiValueChange) to signals of interest and have value change call back > routine just print time stamp and new value. You can then use various > unix tools to compare results. > /Steve > > > -- > Steve Meyer Phone: (612) 371-2023 > Pragmatic C Software Corp. email: sjmeyer@pragmatic-c.com > 520 Marquette Ave. So., Suite 900 > Minneapolis, MN 55402Article: 40951
If ordinary users are discouraged from using this Factory_JF feature in Virtex-II, how about Virtex/Virtex-E/Spartan-II/Spartan-IIE's ability to add some extra delay on the global clock buffer? I believe in bitgen, the user can add extra delay on the global clock buffer to get some extra setup time, but the problem I have is that the feature is sort of secret, and only Xilinx knows how to use it. The default value of that feature in bitgen I believe is 11111 (probably a binary value). My guess is that the value 11111 puts the least amount of global clock buffer delay, and the value 00000 puts the greatest amount of global clock buffer delay. Beyond that, I have no idea how the thing works, but putting too much delay on the global clock buffer will affect Tco, so my guess is that typically people who use it pick a value somewhere in between that. Or looking at it differently, changing one of the bit to 0 (like changing 11111 to 11011) puts certain amount of delay, and more the bits that are zero (like 10011 or 10001), more the delay on the global clock buffer. Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.)Article: 40952
Other people recommended instantiating two designs in one top module, and run both of them from a top module. I guess your idea will be to XOR the outputs coming from the two modules to see when they won't match. I guess that is possible in theory, but I rather see both waveforms untouched myself. Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.) Muzaffer Kal wrote: > > > You don't need to run two instances. Just instantiate both designs in > a test bench and xor the outputs. > > Muzaffer Kal >Article: 40953
On Mon, 18 Mar 2002 19:01:30 GMT, "Kevin Neilson" <kevin_neilson@removethis-yahoo.com> wrote: >I've built an NCO and all digital PLL. The NCO operates at the rate of >sample_clk, and the digital PLL adjusts the NCO phase increment so the NCO >output, theta, represents the angle of a vector spinning at some ratio M/N >times another clock, data_clk. Theta is used as the input for an sine >lookup to produce symbol_clk. So the relationship of the clocks is: > >symbol_clk = M/N * data_clk > >The phase relationship is not important. Both symbol_clk and sample_clk can >change frequencies, so the all-digital PLL must continuously track and >change the frequency of symbol_clk so maintain the above relationship. > > Everything seems to be working well, but I want to optimize everything to >increase the spectral purity of symbol_clk. I would like to know how much >precision I need for the NCO, how to trade off lock time and spectral >purity, and over how long a period I should calculate the frequency error. >Also, should the frequency error be a function of the number of complete >rotations of theta, or also of the fractional part of theta? Do I need to >dither the least-significant bits of theta? I have searched, but can find >little information about such loops. Anyone know of a source of good info? > >-Kevin Kevin, First, thanks for an explicit and clear description of what you're doing and what your questions are. An excellent first step in getting something useful out of this group. If you're actually phase locking the output symbol_clk to data_clk, then the frequency relationship will be fixed, so I'm not sure what you're really after when asking about the frequency error. There isn't one in a PLL, since the "lock" is between the output and the reference. If there _is_ an error, then you're experiencing cycle slips somewhere, which is a solvable problem. Dithering the LSBs of the NCO phase increment register can help reduce the spurious signals in the output, but if you're output is clean enough for your application then there's no need to bother. These are the usual tradeoffs with this sort of architecture, though, so that is a pertinent question. Qualcomm and ADI have both published some very good app notes on NCO/DDS implementations over the years, so you may look around for those if you haven't already. I think there are some other links around that could probably be found with suitable keywords in google (I don't have any directly handy). Perhaps some others will chime in with useful references. Eric Jacobsen Minister of Algorithms, Intel Corp. My opinions may not be Intel's opinions. http://www.ericjacobsen.orgArticle: 40954
> Kevin, > > First, thanks for an explicit and clear description of what you're > doing and what your questions are. An excellent first step in getting > something useful out of this group. > > If you're actually phase locking the output symbol_clk to data_clk, > then the frequency relationship will be fixed, so I'm not sure what > you're really after when asking about the frequency error. There > isn't one in a PLL, since the "lock" is between the output and the > reference. If there _is_ an error, then you're experiencing cycle > slips somewhere, which is a solvable problem. > > Dithering the LSBs of the NCO phase increment register can help reduce > the spurious signals in the output, but if you're output is clean > enough for your application then there's no need to bother. These > are the usual tradeoffs with this sort of architecture, though, so > that is a pertinent question. > > Qualcomm and ADI have both published some very good app notes on > NCO/DDS implementations over the years, so you may look around for > those if you haven't already. I think there are some other links > around that could probably be found with suitable keywords in google > (I don't have any directly handy). Perhaps some others will chime in > with useful references. > > > Eric Jacobsen > Minister of Algorithms, Intel Corp. Eric, By "frequency error" I just mean the feedback signal. Basically, I count how many times the vector theta revolves in N periods of data_clk, and then I subtract this from M to yield the "error". This feedback signal is multiplied by a gain value and then added to the phase incrment that controls the NCO frequency. One thing I'm trying to figure out is the effect of using a ratio of (S*M)/(S*N), which is the same ratio, but with top and bottom multiplied by S. This decreases the loop gain, but does it add precision? -KevinArticle: 40955
hi folks, I've trolled google and the XESS web pages but no luck, so here goes. The XESS parallel prorgamming cable - what are the connections? IT's a DB25-DB25 - is it a simple pass-through (I hope) or something a bit omre tricky? I've got an old XESS XS40 board but the cable is lost in the mists of time. any help greatly appreciated. Thanks, JohnArticle: 40956
hi again, Snag number 1 - Xilinx Webpack does not appear to support the XC4010E that is on my Xess board. any helpful advice? Thanks, JohnArticle: 40957
Are there any Xilinx Spartan FPGAs that are pin compatible with Altera 10k50v-208 parts ? I designed a board initially with the 10k50v parts, but I have had so many problems with Altera, so I would like to drop a Xilinx device on the pads instead. Is there any hope, or am I stuck forever with Altera ?Article: 40958
I tried downloading the Hyperlynx demo and found that it won't let you do anything at all useful. I can enter my own data, but I can't simulate it. I can simulate and example file, but I can't change anything to try to fix problems, or it won't simulate again. This would appear to be a very useless demo. It is not demoing anything except the installation, which did go very smoothly. Isn't this the tool that you said we could do simple things with? I thought the main limitation was that data could not be saved or printed? Austin Lesea wrote: > > Rick, > > Use the fast/strong IBIS corner, and that covers the worst case for > process/voltage/temperature. > > The capactances don't matter all that much (convince yourself by changing them, > and you will see that the results don't change much at all). > > The claim of IBIS simulator vendors is that it saves all of the PCB spins to fix > SI, and they are right. The sims are not that fussy, and all you need to be sure > of are the parts and their models, and the PCB impedance and the lengths. > > Input models are not fussy either, hence my use of VII for all inputs is probably > +/- 10% of the real measured result. All CMOS inputs look pretty much the same. > > If you have wide buses, then crosstalk is important, and you need a little more > detail for the geometry. > > Austin > > rickman wrote: > > > Thanks for your comments John. > > > > I guess I am a little green with clocks above 50 MHz. I was expecting > > runs this short to be pretty simple and not to have to do too much to > > make it work. But with the input from Austin and yourself as well as > > some others, I do at least plan to take a first pass at a simulation. > > My main concern is that you have to know a lot of details about the > > board to run a USEFUL simulation. I have learned a lot from reading > > some of Bob Pease's articles and I fully realize that a simulation won't > > do me a lick of good if I don't make all the right assumptions. > > > > I have been working on a very tightly packed switching power supply > > while I am doing the digital stuff and I am finding that I can make it > > look pretty feasible if I make THESE assumptions and I can make it look > > pretty impossible if I make THOSE assumptions. I think we won't really > > know how well it will work until we fire it up on the final board > > layout. I expect that we will see the same sort of thing with this > > clock design. > > > > I did consider using a zero delay buffer. But this board is very tight > > for space and I have a hard time justifying it with 1.5 inch traces. > > But if the simulation shows a problem, of course we will do what we have > > to. > > > > The SDRAM and SBSRAM are 4 pF input cap max, the FPGA says 8 pF max. > > This is another difference between the simulation Austin did and what I > > have. He seems to have used all VII inputs with 10 pF capacitance. > > > > It is also not clear to me if the simulations are being done with > > typical values or worst case values. If typ values are used, then I > > don't see how the results have any meaning at all. > > > > Rick Collins > > > > John_H wrote: > > > > > > 85 ps per inch works for free space. A better approximation would be 170 ps > > > per inch for internal traces where the relative permitivity of about 4 for > > > FR4 material at high frequency gives a good approximation (sqrt(4) for > > > scaling to free space). The outside traces are a bit faster because they're > > > propagating through a combination of air and FR4 - I don't have the numbers > > > handy for those speeds. > > > > > > You're right about the stackup being important - the trace widths and plane > > > spacings need to be well specified by you to get the board house to provide > > > impedances that won't over/undershoot. A little mistermination is fine - > > > the mid-transition reversals are what kills; those can occur when the > > > driver sees a low impedance for much of the risetime but gets the reflection > > > coming back before the clock's out of the transition region. There's the > > > beauty of SI - this general info gets applied. > > > > > > With everything close and distributed capacitance throughout, you could get > > > smooth transitions with the star configuration, but it's dependent on the > > > drivers and input capacitance. > > > > > > Are independent clocks from the FPGA something you want to avoid? "Zero > > > delay buffers" are part of the clock management's best application. It's > > > often better from a debug standpoint to have access to individual > > > terminations if things go desperately wrong. > > > > > > rickman wrote: > > > > > > > Austin, thanks for the simulation. > > > > > > > > This looks like great data. But I am not sure if you were trying to > > > > help by doing my simulation for me, or if you were just trying to show > > > > what the tool can do. > > > > > > > > I am not clear about what this is simulating. Obviously you used the > > > > daisy chain model, but how do you know what to use as a trace impedance > > > > and where did the delays come from? The preliminary layout I am using > > > > has the following delays in the daisy chain case, assuming 100pS per > > > > inch. Is that a valid assumption? > > > > > > > > DSP to FPGA 100pS > > > > FPGA to SDRAM1 50pS > > > > SDRAM1 to SDRAM2 50pS > > > > SDRAM2 to SBSRAM 100pS > > > > > > > > Don't I need to caclulate the trace impedance from the PCB design > > > > rules? The PCB will be 5 mil trace and 5 mil space with 6 or possibly 8 > > > > layers with a total thickness of 0.062". Of course, I can use wider > > > > traces for the clock and control which layer they are on. > > > > > > > > I would expect these four loads to behave much better than the five > > > > loads with 200+ pS delays. > > > > > > > > If you were just trying to demonstate the tool, that's fine. But if you > > > > were trying to simulate my case, these are the data that should be > > > > used. > > > > > > > > When I am done my other work today, I will try downloading the software > > > > and giving it a try this weekend or next week. > > > > ...snip... > > > > -- > > > > 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 FAX -- 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: 40959
Dear Fellow FPGA designers, I would like to have your feedbacks / supports. Synplicity has released Synplify 7.0.x with lots of enhancements last November. One of the enhancements is called "Tri-state push thru" feature. The following are excerpts from e-mails from Synplicity explaining how the feature works: > For example in the verilog code > > assign data = en ? data_in : 1'bz; > always @(posedge clk) > begin > q_out = data; > end > > will be implemented with tristate after the q_out flipflop currently ( 7.02 > ) to match simulation. The tristate will be implemented > before the q_out flip flop with the switch ( 6.2.4 behavior). > In 6.2.4 we didn't perform Tri-state push through across boundaries > as like every other Synthesis tool on the market. We (and many > of our customers) deemed this logically incorrect. We enabled > Tri-state push thru in 7.0, but some of our customers requested > a 'compatibility' switch so that our results matched our competition, > hence the switch in 7.1. > This switch fixes what we consider to be bad logic and was a > definite requirement from our customers. Simply saying, Synplify 7.x will implement the logic differently from the RTL code you have specified to prevent simulation from causing a mismatch. I have noticed this new feature because my design becomes 30% larger and yet slower when I resynthesized my existing design using Synplify 7.0.2. With this feature: 1086LUTs (30.2MHz) <<-- default in Synplify 7.x W/o this feature : 833LUTs (31.8MHz) My design uses tri-state gates to implement a multiplexer with a large number of inputs efficiently which is a widely used FPGA technique. I hand-crafted the multiplexer such that speed and logic size are both satisfied. Synplify 7.x will implement the multiplexer using LUTs and put a tri-state gate after the LUTs. (tri-state gate is pushed-thru) I thought this feature was creating more harms than goods. Not only because I'm getting inferior results but also I feel the synthesis tool should deliver the exact logic which the input RTL code specified. (Otherwise, FPGA designers can not control how the logic is laid out.) Note: Synplify 7.1 has a switch to select this feature. However this feature is always turned on by default. However, the response I got from Synplicity is quite different from what I had imagined. After many e-mail exchanges, Synplicity has notified me their conclusion: > We still strongly feel that disabling the Tri-state push thru by > default would hurt too many of our customers - who specifically > demanded this feature. We have accommodated for those customers > who prefer the legacy implementation by adding the switch. > > We have several test designs with test-benches which clearly > show RTL / simulation mismatches with this switch disabled. > > Our senior management strongly believes this decision is correct > and in-line with our policy of correct logic implementation. Unfortunately, their conclusion is completely opposite to my understanding. I'm still not convinced that such logic mapping is correct. Since Synplify is #1 in the FPGA synthesis market, a huge number of engineers in the world are using Synplify to design FPGAs. I would like to ask everyone about this new feature of Synplify 7.x. If you feel this feature is incorrect and dangerous (or support Synplicity's arguments), please send me an e-mail. I will present all e-mails I receive to Synplicity (both for and against). Feedback / support to : synp_petition@usa.net I will post the update when I have something to report. Thank you for your attention. Hope I can hear from many of you. You can forward this to any other newsgroups or your friends to get more feedbacks. Sincerely yours, Aki Niimura - being a Synplify user since 1999 P/S I have created a Web site to list feedbacks I receive. http://www.petition-synplify.0catch.comArticle: 40960
Is anyone aware of any freestuff available?Article: 40961
Subject: Parallel Cable III/IV These JTAG pods have attachments called "flying leads", where end #1 is a fixed connector to plug into the pod (i.e., JTAG row of pins) and end #2 is the actual flying leads to connect to the target hardware. That's great for prototype & engineering development, but for production, the actual flying leads @ end #2 can easily be mis-placed by technicians on the assembly line. Is there any readily available, fixed-connection cables (and mating sockets) for the Xilinx-programming-pod-2-target-hardware connection? Or is that some tooling that every customer just has to make on their own w/ catalog parts from Newark, Digi-Key, etc., ? -- ============================== William Lenihan lenihan3we@earthlink.net ==============================Article: 40962
i think it is useless adding constrain(eg.clock/input delay/output delay) in the logic synthesis stage.because it doesn't include any delay timing.it should only be added in the P&R stage(clock/setup/offset/in/out...). amn't I?Article: 40963
usually,i write state machine according the following style.
isn't it?
************************************
`define Present_Crs_State 4:1
`define C_Idle 1
`define C_Rxdv 2
`define C_Wait 3
`define C_Togg 4
//restore signal state machine
assign State_Rxdv = Present_Crs_State[`C_Rxdv];
assign State_Wait = Present_Crs_State[`C_Wait];
assign State_Togg = Present_Crs_State[`C_Togg];
always @(posedge RefClk50 or negedge Rst_N )
begin
if (!Rst_N)
Present_Crs_State <= 4'b0001;
else
Present_Crs_State <= Next_Crs_State;
end
always @ ( Present_Crs_State or
Crsdv
)
begin
Next_Crs_State = 4'b0000 ;
case (1'b1) //synopsys parallel_case full_case
Present_Crs_State[`C_Idle]:
begin
if (Crsdv&&!Rx_Disable)
Next_Crs_State[`C_Rxdv] = 1;
else
Next_Crs_State[`C_Idle] = 1;
end
Present_Crs_State[`C_Rxdv]:
begin
if (Crsdv)
Next_Crs_State[`C_Rxdv] = 1;
else
Next_Crs_State[`C_Wait] = 1;
end
Present_Crs_State[`C_Wait]:
begin
if (Crsdv)
Next_Crs_State[`C_Togg] = 1;
else
Next_Crs_State[`C_Idle] = 1;
end
Present_Crs_State[`C_Togg]:
begin
if (Crsdv)
Next_Crs_State[`C_Idle] = 1;
else
Next_Crs_State[`C_Wait] = 1;
end
default:
Next_Crs_State[`C_Idle] = 1;
endcase
end
Article: 40964
hamish@cloud.net.au wrote:
>
> Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote:
> > I guess the XST is not the only synthesis tool that has this
> > problem.
>
> I wouldn't say it's a problem. Generally speaking it is a helpful
> thing for it to do. It makes the code look better if you only have
> a single output enable signal, rather than manually creating N of them.
>
> It's a fact of life that if you want something different from the
> obvious behaviour, you have to fight the tools for it. The tool thinks
> it is optimising the design for you. But the tools just aren't very
> good at optimising really high speed stuff.
>
It is not a bug, but what XST is doing is different than what I
want it to do.
That alone makes it a problem, but I have to admit that it is not a huge
issue in 33MHz PCI.
Yes, having only one OE FF for the 32-bit bus as opposed to having to
duplicate an OE FF 32 times may make the code look better, but in my
opinion, duplicating it 32 times manually is not a big problem since,
"ad_Port_OE <= 1'b0;" is only changing to "ad_Port_OE[31:0] <=
32'h00000000;".
I personally can live with such an inconvenience, but I cannot live with
inconvenience of the synthesis tool going against my will, and
duplicating an OE FF 32 times.
I think XST has to "trust" the user a little more, and not guess what
the user is trying to do.
> A while back I was having trouble getting a design routed, so I started
> fiddling with the manual fan-out control. I changed the value and looked
> at the tool's speed estimate. I found an optimal value according to
> the tool -- but the optimal value at route time was different again.
> So I don't pay too much attention to the estimated clock speeds.
>
> The automatically duplicated signals are only half as effective as
> they could be due to register ordering performed by Xilinx MAP.
> The synth tool companies need to do something to work around this
> ASAP. In the longer term, Xilinx urgently needs to provide an
> attribute that can be applied to signals to disable this behaviour.
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
Are you talking about synthesis tool's estimated frequency?
I guess in a large design, knowing the estimated frequency at synthesis
stage makes sense because I am told that P&R can take awful long time,
but in my case, I find XST's frequency and setup time estimate pretty
much meaningless, so I go ahead and P&R the design with the lowest
possible P&R effort only once to save time.
In a PCI IP core, setup time is the key, and what determines the setup
time is levels of LUT, so after P&R, I go read the timing report to see
how many levels of LUT XST generated.
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 40965Hi there, I am designing a general I/O board with a Virtex II (xcv2V3000 to 8000) and some memory. I have about 100 spare pins. I have read on the newsgroups sometime ago that it was good to connect them to ground an to assign a value to each of them. Did anybody went through this problem yet ? Also, an external clock will be connected directly to the FPGA. The range is 0-200 MHz. I assume it requires a input filter between the connector and the FPGA. I thought about a low pass filter with a cut frequency of 200 MHz. Does it sound good ? Thanks. Philippe.Article: 40966
Hi,
I'm using LeonardoSpectrum v2002a to synthesise to EDIF. P&R is with
Xilinx Webpack 4.1WP3.x. Target device is Spartan IIE (XC2S200E).
A couple of pins need to be tied high, and this is achieved in the
EDIF by connecting to port P of a VCC component. This happens from
within a hierarchical block.
The P&R leaves the pin unconnected and floating. I've checked this
with the floorplanner. Should I be using a different name for the
power net, or is this likely to be a problem with hierarchical EDIF?
Anybody got any suggestions?
Cheers,
Dave.
Article: 40967I can't understand how a FIFO could work well if it is writed with an high data rate and it's read with a low data rate, from my point of view, reallt soon it became full and all the data that continue to be writed into the FIFO will put away the first data, where's my conceptual error ?? AntonioArticle: 40968
Antonio wrote: > > I can't understand how a FIFO could work well if it is writed > with an high data rate and it's read with a low data rate, from > my point of view, reallt soon it became full and all the data > that continue to be writed into the FIFO will put away the first > data, where's my conceptual error ?? Hi There's no error: what goes in must go out and if it doesn't go out fast enough it'll be overwritten. It's much more useful the other way round: data come in slower *on average* than they go out. Think of bursts of data (high instantaneous bit rate) -- Nicolas MATRINGE IPricot European Headquarters Conception electronique 10-12 Avenue de Verdun Tel +33 1 46 52 53 11 F-92250 LA GARENNE-COLOMBES - FRANCE Fax +33 1 46 52 53 02 http://www.IPricot.com/Article: 40969
Antonio wrote: > > I can't understand how a FIFO could work well if it is writed with an > high data rate and it's read with a low data rate, from my point of > view, reallt soon it became full and all the data that continue to be > writed into the FIFO will put away the first data, where's my > conceptual error ?? No error. If the fifo gets full, you need to stop filling it.Article: 40970
Does any of you know some sites where I can view examples of DDS inplemented in an FPGA? thx motArticle: 40971
Try http://www.xilinx.com/xlnx/xil_prodcat_landingpage.jsp?title=ISE+WebPack the free package is very powerfull , be sure you have a large disk space and fast internet download access. regards -- Use our news server 'news.foorum.com' from anywhere. More details at: http://nnrpinfo.go.foorum.com/Article: 40972
You can browse through www.andraka.com. He has something on CORDIC used in direct digital frequency synthesis. Does DDS mean direct digital synthesis? -- Email: qijun@okigrp.com.sg "Mot" <mister_mot@hotmail.com> wrote in message news:a75cd014.0203190324.46563ed6@posting.google.com... > Does any of you know some sites where I can view examples of DDS > inplemented in an FPGA? > > thx motArticle: 40973
John Williams wrote: > hi folks, > > I've trolled google and the XESS web pages but no luck, so here goes. > > The XESS parallel prorgamming cable - what are the connections? IT's a > DB25-DB25 - is it a simple pass-through (I hope) or something a bit omre > tricky? It is a simple pass-through cable. Questions like this can be sent to help@xess.com or submit the form at http://www.xess.com/help.html. > > > I've got an old XESS XS40 board but the cable is lost in the mists of > time. > > any help greatly appreciated. > > Thanks, > > John -- || Dr. Dave Van den Bout XESS Corp. (919) 303-2883 || || devb@xess.com 2501-B Ten-Ten Road (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 303-2884 ||Article: 40974
John Williams wrote: > hi again, > > Snag number 1 - Xilinx Webpack does not appear to support the XC4010E > that is on my Xess board. any helpful advice? You could buy the Xilinx Student Edition 2.1i for $55.00. It supports the XC4000E and XC4000XL series. Or you could buy an XSA-100 Board that is supported by WebPACK and has the same form factor as the XS40 Board. > > > Thanks, > > John -- || Dr. Dave Van den Bout XESS Corp. (919) 303-2883 || || devb@xess.com 2501-B Ten-Ten Road (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 303-2884 ||
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