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
> Sounds interesting. What do you mean by that? Could you please go a > little > bit more into details? I heard about "source synchronous busses" a while > ago > but unfortunately I don't know what it is... sorry! Wikipedia has a good article : http://en.wikipedia.org/wiki/Source-synchronous Basically when A sends stuff to B : - A and B can be clocked by the same global clock (the good old way, with clock skew etc) - B can generate a clock and send it to A (then you get problems if traces are long) - A can generate a clock and send it to B Last case means, A (source) can send a clock that is perfectly synchronized with the sent data. Hence, if clock and data go through the same trace length, B receives well synchronized clock and data, so B's flip flops are happy. Of course, A's clock will not have the same phase as B's internal clock, so B needs some way of putting them back in phase (FIFO, etc). One could argue that stuff like SATA or Ethernet are source synchronous, too, even though there is no separate clock, as it is embedded in the data. It would not be possible for the controller to clock the harddisk when the frequency is so high that the length of the cable contains several different bits propagating along the transmission line !Article: 121826
Hello, I have used a FPGA module, XPS, microblaze, verilog etc for a personal project. This was very interesting and now, I am trying to design my own FPGA mini board. This is also a learning experience, and of course, because I like that stuff. It turns out to be very interesting. I have read lots of datasheets, app notes, etc to try to get it right. So, the question is, would experienced people be willing to spend a few minutes reviewing my schematics to tell me if I have some obvious errors ? What format should I use ? I use Eagle, so I can give Eagle files or plain PDF. Thank you, PF. Caillaud From news@REMOVE_tlcs_THIS_dot_TO_fsnet_REPLY_dot_co.uk Fri Jul 13 07:55:39 2007 Path: newsdbm04.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!goblin1!goblin.stu.neva.ru!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!news.clara.net!wagner.news.clara.net!monkeydust.news.clara.net!demeter.uk.clara.net From: "Tom Lucas" <news@REMOVE_tlcs_THIS_dot_TO_fsnet_REPLY_dot_co.uk> Newsgroups: comp.arch.embedded,comp.arch.fpga,comp.arch,sci.electronics.design,sci.electronics.components References: <469653f8$0$3834$9b4e6d93@newsspool4.arcor-online.net> <1184290335.145967.165170@q75g2000hsh.googlegroups.com> <46971c5b$0$3830$9b4e6d93@newsspool4.arcor-online.net> <nPGdnWZQAqSCEArbnZ2dnUVZ8vidnZ2d@giganews.com> Subject: Re: highly-parallel highspeed connection between two FPGA boards Date: Fri, 13 Jul 2007 15:55:39 +0100 Lines: 18 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.3138 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Complaints-To: abuse@clara.net (please include full headers) X-Trace: 6f61570c26aa6000141c2c6c1af560a517829553d66c6408705c428a4697924f NNTP-Posting-Date: Fri, 13 Jul 2007 15:55:11 +0100 Message-Id: <1184338511.65803.0@demeter.uk.clara.net> Xref: prodigy.net comp.arch.embedded:256370 comp.arch.fpga:133696 comp.arch:183115 sci.electronics.design:823346 sci.electronics.components:146576 "Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote in message news:nPGdnWZQAqSCEArbnZ2dnUVZ8vidnZ2d@giganews.com... > > "Maurice Branson" <traubenuss@arcor.de> wrote >> >> Oay, to make it more precise: I'm looking for an interconnect system >> (multi-channel plug + receptacle) for 24 differential pairs at >> signaling rates of 3 - 6 Gbps per channel. > > I don't know if you have already looked at them, but for things like > that, I use Samtec connectors and cables. > http://samtec.com/high_speed_connectors/2006/si_b2b.asp > http://samtec.com/high_speed_connectors/2006/SI_C2B.asp?m=hs I can recommend Samtec as well - very fast service and samples turn up in under two days. Knowledgable reps too.Article: 121827
"Maurice Branson" <traubenuss@arcor.de> wrote in message news:46971c5b$0$3830$9b4e6d93@newsspool4.arcor-online.net... > Tanks for your answers so far! > > Oay, to make it more precise: I'm looking for an interconnect system > (multi-channel plug + receptacle) for 24 differential pairs at signaling > rates of 3 - 6 Gbps per channel. So, I assume it is a motheboard-daughtercard kind of connection, right? I am running Xilinx Rocket IOs at 3.36 Gb/s over the standard cPCI connectors (front card to/from rear card through the backplane, but not across the backplane) with no problems. Since these connectors aren't designed/specified for such speeds I had to develop my own grounding solution. Basically, I have enclosed each of the differential pairs in between GND pins and it worked really well both in simulation and in real life. Also, I am not sure what exactly you are up to, but consider doing some upconversion on your DAC board (maybe even in the DAC itself). By doing this you might be able to reduce your communication bandwidth requirements substantially. /MikhailArticle: 121828
How about this? module counter ( clock, reset1, reset2, counter ); input clock ; input reset1 ; input reset2 ; output [3:0] counter ; wire clock ; wire reset1 ; wire reset2 ; wire [3:0] counter_c; wire GND ; wire enable ; wire VCC ; wire clock_c ; wire reset1_c ; wire reset2_c ; wire un1_counter_1_axbxc0 ; wire un1_counter_1_axbxc1 ; wire un1_counter_1_axbxc2 ; wire N_7_i_i ; wire enablee_0 ; wire G_1_i_a3_0 ; wire G_2_0_o2_0 ; wire GND_Z ; wire VCC_Z ; LUT4_L N_7_i_i_cZ ( .I0(G_2_0_o2_0), .I1(counter_c[0]), .I2(counter_c[1]), .I3(counter_c[3]), .LO(N_7_i_i) ); defparam N_7_i_i_cZ.INIT=16'hBF40; LUT4_L N_6_i ( .I0(G_1_i_a3_0), .I1(counter_c[0]), .I2(counter_c[1]), .I3(enable), .LO(enablee_0) ); defparam N_6_i.INIT=16'h7F00; // @2:10 FDS enable_Z ( .Q(enable), .D(enablee_0), .C(clock_c), .S(reset2_c) ); LUT2_L G_2_0_o2_0_cZ ( .I0(counter_c[2]), .I1(enable), .LO(G_2_0_o2_0) ); defparam G_2_0_o2_0_cZ.INIT=4'h7; LUT2_L G_1_i_a3_0_cZ ( .I0(counter_c[2]), .I1(counter_c[3]), .LO(G_1_i_a3_0) ); defparam G_1_i_a3_0_cZ.INIT=4'h8; // @2:23 LUT2_L un1_counter_1_axbxc0_cZ ( .I0(counter_c[0]), .I1(enable), .LO(un1_counter_1_axbxc0) ); defparam un1_counter_1_axbxc0_cZ.INIT=4'h6; // @2:23 LUT3_L un1_counter_1_axbxc1_cZ ( .I0(counter_c[0]), .I1(counter_c[1]), .I2(enable), .LO(un1_counter_1_axbxc1) ); defparam un1_counter_1_axbxc1_cZ.INIT=8'h6C; // @2:23 LUT4_L un1_counter_1_axbxc2_cZ ( .I0(counter_c[0]), .I1(counter_c[1]), .I2(counter_c[2]), .I3(enable), .LO(un1_counter_1_axbxc2) ); defparam un1_counter_1_axbxc2_cZ.INIT=16'h78F0; // @2:2 BUFGP clock_ibuf ( .I(clock), .O(clock_c) ); // @2:5 OBUF \counter_obuf[3] ( .O(counter[3]), .I(counter_c[3]) ); // @2:5 OBUF \counter_obuf[2] ( .O(counter[2]), .I(counter_c[2]) ); // @2:5 OBUF \counter_obuf[1] ( .O(counter[1]), .I(counter_c[1]) ); // @2:5 OBUF \counter_obuf[0] ( .O(counter[0]), .I(counter_c[0]) ); // @2:4 IBUF reset2_ibuf ( .O(reset2_c), .I(reset2) ); // @2:3 IBUF reset1_ibuf ( .O(reset1_c), .I(reset1) ); // @2:18 FDR \counter_Z[3] ( .Q(counter_c[3]), .D(N_7_i_i), .C(clock_c), .R(reset1_c) ); // @2:18 FDR \counter_Z[2] ( .Q(counter_c[2]), .D(un1_counter_1_axbxc2), .C(clock_c), .R(reset1_c) ); // @2:18 FDR \counter_Z[1] ( .Q(counter_c[1]), .D(un1_counter_1_axbxc1), .C(clock_c), .R(reset1_c) ); // @2:18 FDR \counter_Z[0] ( .Q(counter_c[0]), .D(un1_counter_1_axbxc0), .C(clock_c), .R(reset1_c) ); GND GND_cZ ( .G(GND_Z) ); VCC VCC_cZ ( .P(VCC_Z) ); endmodule /* counter */ Cheers, JonArticle: 121829
On Jul 13, 7:59 am, backhus <n...@nirgends.xyz> wrote:
> ...
> sch2verilog
> ...
Usually most command issued by the ISE GUI are appended to a file
<PATH_TO_THEPROJECT>/<PROJECT_NAME>.cmd_log
if You cleanup all project files and "rebuild all" You can have in
that file
all the command line to issue to rebuild your project (NOTE ofter the
rebuild You
souldn't re-cleanup the project files else you lose something...and
the command
line couldn't work...)
I don't know if that is the case for "sch2verilog" too... let try !
Sandro
Article: 121830John, Thanks for the tip. This is very helpful. I will need to get a receiver with 100 Ohm termination. I am now assuming that the v5 GTP has 950mV of common mode voltage. In that case my next issue will be how to lower the common mode voltage from 950mv to a voltage between 370mV and 790mV. Austin mentioned that this can be be controlled using MGTVTTTX plane. This plane is 1.2V. If I lower this voltage then will it not lower the voltage swing? I am not sure that by lowering MGTVTTTX, we can ONLY lower the common mode voltage. I am still unable to find a document that shows how to lower the common mode voltage. Thanks. EddieArticle: 121831
Gero, As noted by others, you need a high quality clock to each FPGA. They do not need to be phase matched, or equal length. Just a good very low jitter clock to each one from a clock distribution device (like the ICT quad LVDS clock buffer + cleanup PLL -- a good choice I use -- I think it is a 8745?): http://www1.idt.com/products/files/18378197/ics8745b.pdf?CFID=5561739&CFTOKEN=91108912 or equivalent. The nice thing about some of these parts is that you may use a lower frequency less expensive oscillator, and this part will multiply the frequency, and remove jitter, too (as opposed to buying a much more expensive higher frequency oscillator). This then is the basis for all timing in each FPGA. To get from one FPGA to another, or from one FPGA to an ASIC/ASSP: http://www.xilinx.com/publications/prod_mktg/pn0010778.pdf You would use a source-synchronous interface. This one where you send the data, and a clock from one, to the other. Since the data jitter will be exaclty what the clock jitter is (they came through the same paths, close to each other), system jitter, and clock jitter are almost able to be ignored. The receive side uses the forwarded clock to register the incoming data. Often the DCM is used to phase shift the sample point to exactly the center of the "eye" so you have best timing margin. The data paths with clocks must all be delay matched (all signals must leave and arrive in sync with each other). We have tables of the delay from the silicon, to the pad, and you need to have your pcb designer take this into account. There is also a source synchronous IO block built into V4, and you can do things like use one forwarded clock to frame 4 bits on each wire (the forwarded clock is running at 1/4 the system clock). The SSIO block takes care of the serialization and parallel conversion of each IO. http://direct.xilinx.com/bvdocs/userguides/ug070.pdf Chapter 8. Also look at the SPI POS 4.2 IP core, and how it is specified for inter chip communications (this is an industry standard for wide, fast, DDR buses). So, in review: system synchronous (one clock to all chips) for each chip to use for all of its internals, and generating forwarded clocks; AND source synchronous (a forwarded clock) for each data bus between devices. Searching on "source synchronous" and "spi pos 4.2" and reading the user's guides on the SSIO blocks will get you up to speed. AustinArticle: 121832
That's very interesting. Is it possible to ask for something which compiles at under 20 lines of code? It's beyond my level of understanding. Thanks. "Jon Beniston" <jon@beniston.com> wrote in message news:1184339388.761504.23070@m3g2000hsh.googlegroups.com... > How about this? > > module counter ( > clock, > reset1, > reset2, > counter > ); > input clock ; > input reset1 ; > input reset2 ; > output [3:0] counter ; > wire clock ; > wire reset1 ; > wire reset2 ; > wire [3:0] counter_c; > wire GND ; > wire enable ; > wire VCC ; > wire clock_c ; > wire reset1_c ; > wire reset2_c ; > wire un1_counter_1_axbxc0 ; > wire un1_counter_1_axbxc1 ; > wire un1_counter_1_axbxc2 ; > wire N_7_i_i ; > wire enablee_0 ; > wire G_1_i_a3_0 ; > wire G_2_0_o2_0 ; > wire GND_Z ; > wire VCC_Z ; > LUT4_L N_7_i_i_cZ ( > .I0(G_2_0_o2_0), > .I1(counter_c[0]), > .I2(counter_c[1]), > .I3(counter_c[3]), > .LO(N_7_i_i) > ); > defparam N_7_i_i_cZ.INIT=16'hBF40; > LUT4_L N_6_i ( > .I0(G_1_i_a3_0), > .I1(counter_c[0]), > .I2(counter_c[1]), > .I3(enable), > .LO(enablee_0) > ); > defparam N_6_i.INIT=16'h7F00; > // @2:10 > FDS enable_Z ( > .Q(enable), > .D(enablee_0), > .C(clock_c), > .S(reset2_c) > ); > LUT2_L G_2_0_o2_0_cZ ( > .I0(counter_c[2]), > .I1(enable), > .LO(G_2_0_o2_0) > ); > defparam G_2_0_o2_0_cZ.INIT=4'h7; > LUT2_L G_1_i_a3_0_cZ ( > .I0(counter_c[2]), > .I1(counter_c[3]), > .LO(G_1_i_a3_0) > ); > defparam G_1_i_a3_0_cZ.INIT=4'h8; > // @2:23 > LUT2_L un1_counter_1_axbxc0_cZ ( > .I0(counter_c[0]), > .I1(enable), > .LO(un1_counter_1_axbxc0) > ); > defparam un1_counter_1_axbxc0_cZ.INIT=4'h6; > // @2:23 > LUT3_L un1_counter_1_axbxc1_cZ ( > .I0(counter_c[0]), > .I1(counter_c[1]), > .I2(enable), > .LO(un1_counter_1_axbxc1) > ); > defparam un1_counter_1_axbxc1_cZ.INIT=8'h6C; > // @2:23 > LUT4_L un1_counter_1_axbxc2_cZ ( > .I0(counter_c[0]), > .I1(counter_c[1]), > .I2(counter_c[2]), > .I3(enable), > .LO(un1_counter_1_axbxc2) > ); > defparam un1_counter_1_axbxc2_cZ.INIT=16'h78F0; > // @2:2 > BUFGP clock_ibuf ( > .I(clock), > .O(clock_c) > ); > // @2:5 > OBUF \counter_obuf[3] ( > .O(counter[3]), > .I(counter_c[3]) > ); > // @2:5 > OBUF \counter_obuf[2] ( > .O(counter[2]), > .I(counter_c[2]) > ); > // @2:5 > OBUF \counter_obuf[1] ( > .O(counter[1]), > .I(counter_c[1]) > ); > // @2:5 > OBUF \counter_obuf[0] ( > .O(counter[0]), > .I(counter_c[0]) > ); > // @2:4 > IBUF reset2_ibuf ( > .O(reset2_c), > .I(reset2) > ); > // @2:3 > IBUF reset1_ibuf ( > .O(reset1_c), > .I(reset1) > ); > // @2:18 > FDR \counter_Z[3] ( > .Q(counter_c[3]), > .D(N_7_i_i), > .C(clock_c), > .R(reset1_c) > ); > // @2:18 > FDR \counter_Z[2] ( > .Q(counter_c[2]), > .D(un1_counter_1_axbxc2), > .C(clock_c), > .R(reset1_c) > ); > // @2:18 > FDR \counter_Z[1] ( > .Q(counter_c[1]), > .D(un1_counter_1_axbxc1), > .C(clock_c), > .R(reset1_c) > ); > // @2:18 > FDR \counter_Z[0] ( > .Q(counter_c[0]), > .D(un1_counter_1_axbxc0), > .C(clock_c), > .R(reset1_c) > ); > GND GND_cZ ( > .G(GND_Z) > ); > VCC VCC_cZ ( > .P(VCC_Z) > ); > endmodule /* counter */ > > Cheers, > Jon > >Article: 121833
PF, If this was for a business, we (the FPGA Lab) do this, as a service at Xilinx. Companies send me their schematics in pdf format, along with their board stackup (layer assignments, and thicknesses), and we review them. We do not promise anything (for guarantees, you would need to go to Xilinx Design Services, and pay for a formal review with a formal report), but we do our best to comment on the bypassing, configuration, signal integrity, and whatever else we can see. It is in our best interests that a pcb gets built, and works (parts get ordered that way). But for an individual with a hobby, we are unable to offer this service. Perhaps someone else will volunteer? Good luck. You may also want to look at pcb documentation for demo pcbs that are available on our website: http://www.xilinx.com/products/boards/files/ml401_2_3_schematics.pdf is just one example. AustinArticle: 121834
On Jul 12, 3:12 pm, "craigtmo...@googlemail.com" <craigtmo...@googlemail.com> wrote: > Is there a way to convert a schematic file (.sch) into a functional > verilog module (.v/.vf) from the command line? I want to do this so I > can compile the resulting verilog file with modelsim for simulation. I > know how to do this from theISEGUI, but it would be much easier if I > could do it from the command line. > > Please bear in mind that I am using XilinxISE9.1i or ModelSim XE III/ > Starter 6.2c when posing your answers. > > I appreciate any help you can provide. > > Kind Regards, > Craig. > > P.S. Out of curiosity, is there a way to simulate a project with mixed > verilog and schematic files in ModelSim from the command line? HI Craig, As Eilert pointed out, you can use sch2verilog and sch2vhdl to convert the schematic file that comes from ECS. This is the biggest confusion I am hearing. ECS is the schematic capture tool you probably have never heard this name used before. XST does not write out schematics. XST is the Xilinx Synthesis tool. Basically what happens in the back end is for us to convert it to HDL and then run XST on it. Regarding your question on whether you can mix schematic and HDL in modelsim, the answer is no. Modelsim is a HDL simulator only. It cannot simulate gates. This is why you can psuedo implement this by the method that Eilert provided that is to write a tcl script that runs sch2verilog and then runs the simulation. You can combine the shell script and do file into one Tcl file if you use the exec command. Thanks DuthArticle: 121835
When i try that, I have that kind of error messages: Error: unsupported relocation against buh ?Article: 121836
"Patrick Dubois" <prdubois@gmail.com> wrote in message news:1184331575.895094.145910@n60g2000hse.googlegroups.com... > On Jul 13, 7:19 am, "Symon" <symon_bre...@hotmail.com> wrote: > >> Hi Patrick, >> So I'm still using 8.2, and this isn't the behaviour I see. An import >> overwrites any previous edits. Is this a new feature for 9.1? >> >> > In order to help you setting up the Chipscope Analyzer project, take a >> > look at csptool: >> >http://code.google.com/p/csptool/ >> >> I downloaded it, sounds interesting, many thanks. >> >> All the best, Syms. > > I have been using Chipscope since v7 and I think that it's always been > like that. After you load a new bit file, disconnect and reconnect the > JTAG (JTAG chain menu). Chipscope will then discover that the number > of signals changed and a dialog will pop-up asking if you want to > preserve signals names (choose yes). Then you will see new unnamed > signals in your signals list (they won't be in the waveform). Now you > can simply import the new cdc file to retreive the name of these new > signals. The rest of the Analyzer design should stay intact. > > Cheers, > Patrick > Hi Patrick, So, I followed your instructions, but at the point where I import the new cdc file, the signal names _ALL_ revert to the names in the design, even ones I have renamed. The triggers and busses do remain unchanged, but signals that have been renamed revert their names. Arse! This is with 8.2. Cheers, Syms.Article: 121837
<miche> wrote in message news:469783cb$1_1@mk-nntp-2.news.uk.tiscali.com... >> And please start asking questions rather than telling us something and >> waiting. > > The question was asked two days ago. > I will not repost it. If people can't find it then that's fine. > > I need a counter that count up from 0 to 15 > When reaching 15 or 0 again - stop > Reset1 clears counter to zero > Reset2 starts counter > Language - verilog I'm SERIOUSLY trying to help here and you completely blew off my other questions in this email AND you have NEVER asked a question that I can recall. A question usually involves a question mark. Are you aware what that is? My apologies if you actually did ask questions in your previous posts, but I recall them all as "This is my situation." "Eagerly anticipating your reply." Please look at my response again from this morning and inform us: from what background do you come and how would you approach this in software (if you know programming languages). Don't blow off the ones that are trying to help you because others vent their frustration with your inadequate approach to pursuing information from the other posters on this newsgroup. It's fine if english isn't your first language. It's fine if you're a student. It's fine if you want other people to do your job, just be UP FRONT with this group and we can be a friendly, responsive bunch.Article: 121838
<Eddie H> wrote in message news:eea7f3e.7@webx.sUN8CHnE... > John, > > Thanks for the tip. This is very helpful. I will need to get a receiver > with 100 Ohm termination. > > I am now assuming that the v5 GTP has 950mV of common mode voltage. In > that case my next issue will be how to lower the common mode voltage from > 950mv to a voltage between 370mV and 790mV. > > Austin mentioned that this can be be controlled using MGTVTTTX plane. This > plane is 1.2V. If I lower this voltage then will it not lower the voltage > swing? I am not sure that by lowering MGTVTTTX, we can ONLY lower the > common mode voltage. > > I am still unable to find a document that shows how to lower the common > mode voltage. > > Thanks. > > Eddie The CML signal is most often used with coding like 8B10B that has a DC-balance to the signals if they were AC. I'd suggest looking at an AC decouple. Signal integrity tools *might* give an idea if using capacitor pass elements or two terminations to your common mode voltage rather than one differential termination will provide good results. Inductors can also be used on the receive side of the capacitors to establish a DC level without splitting the resistor in two. If your swing can be reduced, just using a resistor divider to ground on the receiver may give you the voltage swing you want without compromising the transmitter.Article: 121839
On 13 Jul, 16:23, <miche> wrote:
> That's very interesting.
> Is it possible to ask for something which compiles at under 20 lines
> of code?
Damn, I was going to suggest this, but it's 26 lines!
module counter (
input wire clock,
input wire reset1,
input wire reset2,
output reg [3:0] counter
);
reg enable;
always @(posedge clock)
begin
if (reset2 == 1'b1)
enable <= 1'b1;
else if (counter == 4'hf)
enable <= 1'b0;
end
always @(posedge clock)
begin
if (reset1 == 1'b1)
counter <= 4'h0;
else if (enable == 1'b1)
counter <= counter + 4'h1;
end
endmodule
Article: 121840John, I would love to use AC coupling but we have a training sequence where the transmitter needs to drive a static pattern. The protocol does not seem to support the 8b/10b. The data rate is not that high yet. Austin suggested that the V5 GTPs are flexible in this regard but I do not know how to adjust the common mode voltage only. Thanks. Eddie.Article: 121841
On Jul 12, 10:46 pm, Totally_Lost <air_b...@yahoo.com> wrote: > On Jul 12, 11:28 am, Mike Treseler <mike_trese...@comcast.net> wrote: > > > I feel your pain, but the > > fpga manufacturers would have caused > > more pain by going out business. > > There was absolutely no risk forXilinxgoing out of business if it > has spent another man year or two software engineering labor to > include XC4K/Spartan support into XST. A few hundred thousand dollar > cost to provide the expected support for probably $100M of product > they forced early obsolecence of by that ommission., > > What they did do was hurt a lot of small businesses like mine and my > clients at the time, and thousands of students. > > That created a burst of new product sales, as people scrambled to > reengineer with Spartan 2's and Virtex parts. One of my former clients > was so angry about almost being put out of business by it, they will > never buyXilinxagain. > > And today we have Austin crowing about others circling the drain, and > how they commit to customer support, and always have. > > Bull Pucky .... outright .... > > At any point since, they could have included XC4K/Spartan synthesis in > XST while highly profitable, as Austin continuously touts, the highest > margins in the industry. But no ... they screwed a lot of people, and > didn't even look back to make a buck. Hi, The question is not whether Xilinx can add 4k device family support in XST. The question is at what cost. Everything costs resources and would mean giving up on something else. Would everyone be happy if XST did not support the latest architecture for Inference and also did not have good language coverage at the cost of supporting synthesis for the now 4 yr old 4K device family? I would think not. If Xilinx has infinite supply of resources this can be done. The reality is that there are no inifinite resources, so there has to be some compromises that have to be made. Also note that Xilinx does provide software support other than synthesis in XST. You can download the ISE Classics from the website for all the implementation tools. In general nothing was removed something was just not added. If this is a major issue anyone can work with Mentor or Synplcity for their synthesis tools to synthesize the designs. Pricing can be an issue, although I am sure they can give eval versions if they were asked. Thanks DuthArticle: 121842
Hello, I have just tried to compile this, I am receiving 2 warnings WARNING:ProjectMgmt - "C:/tt/counter/counter.ngr" line 0 duplicate design unit: 'Module|counter' WARNING:ProjectMgmt - "C:/tt/counter/counter.nga" line 0 duplicate design unit: 'Module|counter' Is this important?Article: 121843
On Jul 13, 11:36 am, "Symon" <symon_bre...@hotmail.com> wrote: > Hi Patrick, > So, I followed your instructions, but at the point where I import the new > cdc file, the signal names _ALL_ revert to the names in the design, even > ones I have renamed. The triggers and busses do remain unchanged, but > signals that have been renamed revert their names. Arse! > This is with 8.2. > Cheers, Syms. Oh, I had misunderstood your problem. Yes the signals names will revert to the ones in the cdc file... What is kept is things like colors, buses you created, triggers... But not the names, sorry about the confusion! I never ran into that problem because I don't change the names of the signals. Yet one more simply feature that the Chipscope GUI should have... If you really need that feature, you could try to modify the csptool script to create a "custom cdc import" feature. That would be fairly involved however because csptool can only parse .cpj files, not .cdc ones. Alternatively, you could try to modify the cdc file to only keep the new signals, and then import this partial cdc file. If you're lucky it will work... PatrickArticle: 121844
Yes I connect the DCM's outputs, CLK0_OUT, CLK90_OUT and CLK2X_OUT to the MiG interface's input ports clk_0, clk_90 and clk_200. My reference clock is 100 MHz SYSCLK_100MHZ on pin AE14. You are right about the global routing, but with it I get these errors : ERROR:NgdBuild:770 - IBUFGDS 'CLKFB_IBUFGDS_INST' and IBUFGDS 'CLKFB_IBUFGDS_INST' on net 'N0' are lined up in series. Buffers of the same direction cannot be placed in series. So do I need to edit the VHDL of the MiG interface to remove the buffer from its DCM's input? The best solution for me is via my main schematic file, thanks.Article: 121845
On 13 Jul, 17:29, <miche> wrote: > Hello, > I have just tried to compile this, I am receiving 2 warnings > > WARNING:ProjectMgmt - "C:/tt/counter/counter.ngr" line 0 duplicate design > unit: 'Module|counter' > WARNING:ProjectMgmt - "C:/tt/counter/counter.nga" line 0 duplicate design > unit: 'Module|counter' > > Is this important? Not to me.Article: 121846
<Eddie H> wrote in message news:eea7f3e.9@webx.sUN8CHnE... > John, > > I would love to use AC coupling but we have a training sequence where the > transmitter needs to drive a static pattern. The protocol does not seem to > support the 8b/10b. The data rate is not that high yet. Austin suggested > that the V5 GTPs are flexible in this regard but I do not know how to > adjust the common mode voltage only. > > Thanks. > > Eddie. So what about the other comment? Simple resistor divider at the receiver?Article: 121847
Yes, this is should be great, I am just going to put it in my toplevel, and simulate. Thanks a lot. (are you available for more questions?)Article: 121848
Hi Duth, You missed the point, actually several. First we are talking about what Xilinx should have done 4 years ago, when they got into the licensing problem with FPGA Express. Second, both XC4K and Spartan devices were still relatively current devices at that time, as they were still being stuffed on boards, but generally not recommended for new designs. Third, there were a huge number of them in current use, especially in the educational market. Last, the cost to Xilinx to include XC4K/Spartan support in XST would have been relatively minor, maybe a man year or two. And as you note, the hard part was already done, working, and shipping ... the place and route, plus bit stream utilities which are the most device dependent. While I've not seen the XST code, I would not have been suprised if the difference between Spartan 2 support and providing XC4K/Spartan support XST was actually less than a man year. There are still a large number of these student boards floating around, without any affordable VHDL/Verilog synthesis support. So, the point is, this is a clear example of Austin's hype about Xilinx's high moral support position being perfect, and other competitors poor, is simply wrong -- and in my mind -- an outright lie.Article: 121849
> I'm SERIOUSLY trying to help here and you completely blew off my other > questions in this email AND you have NEVER asked a question that I can > recall. A question usually involves a question mark. Are you aware what > that is? My apologies if you actually did ask questions in your previous > posts, but I recall them all as "This is my situation." "Eagerly > anticipating your reply." Please look at my response again from this > morning and inform us: from what background do you come and how would you > approach this in software (if you know programming languages). Hello, I received the info from another member. Just to be clear, I don't really like your question if I am professional or hobbyist, also, you do not explain how you define hobbyist/professional. Personally, I don't think it matters, some professionals are amaturish, and some amatures are professional. Don't try to put people into boxes.
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