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
On 25 Mai, 16:33, johnp <johnp3+nos...@probo.com> wrote: > On May 25, 12:11 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > > > On 24 Mai, 16:35, Peter Alfke <a...@sbcglobal.net> wrote: > > > > You can define the BRAM content through configuration, and you can > > > then use the BRAM as a ROM, just by never writing new information into > > > it. > > > But remember: > > > Reading from a BRAM is a synchronous operation. You must supply a > > > clock, and the Data output changes only after the rising edge of the > > > clock. > > > Also, in order to guarantee the integrity of the ROM content, you > > > should not change the addresses during the set-up time window before > > > the clock, while CE is active. (WE inactive is not sufficient to > > > protect against all address set-up time violations). This is not > > > intuitively obvious. > > > Peter Alfke, Xilinx > > > ======================= > > > On May 24, 7:07 am, Lancer <peppe...@gmail.com> wrote: > > > Hi Peter, > > > isnt that address setup time requirement only there for Virtex-4 > > because of silicon errata? > > or can the memory corruption occour on other Xilinx FPGA's as well? > > > Antti > > Antti - > > As I recall, V2Pro has a similar corruption "feature" for the BRAMS. > > John Providenza- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - ah s.... when I first read it, I assumed its only Virtex-4 related silicon bug. I could not belive the same errata is present and not fixed in more then one Xilinx FPGA Family. guess need read again all datasheets and erratas :( AnttiArticle: 119751
On 25 mayo, 12:32, Antti <Antti.Luk...@googlemail.com> wrote: > On 25 Mai, 12:20, Pablo <pbantu...@gmail.com> wrote: > > > I have a SMT338 board. This is a FPGA module and now I want to add a > > DDR SDRAM to my system. I have the ucf file provided by the company > > but in this file I don't find ddr_feedback clock. What it means?. I > > suppose that this pin is neccesary, but there is no pin called > > "feedback" or "clk_fb" or "clk_ddr". I only see the clock signal "ck" > > y "ckn" but these signals are used by the fpga to the ddr. > > > Has anyone the solution?. > > > Regards > > there are different IP cores, some use the extra feedback pin some > dont. > > boards that have the extra pin are better as they are easier to work > with. > > if you happen to have a board with no feedback pin then you need > either use IP core > that does not utilize the feedback, or make some workaround to the > existing IP core > so you can still use it. > > Antti Do you know for some core without feedback?.Article: 119752
On 25 Mai, 16:45, Pablo <pbantu...@gmail.com> wrote: > On 25 mayo, 12:32, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > > > On 25 Mai, 12:20, Pablo <pbantu...@gmail.com> wrote: > > > > I have a SMT338 board. This is a FPGA module and now I want to add a > > > DDR SDRAM to my system. I have the ucf file provided by the company > > > but in this file I don't find ddr_feedback clock. What it means?. I > > > suppose that this pin is neccesary, but there is no pin called > > > "feedback" or "clk_fb" or "clk_ddr". I only see the clock signal "ck" > > > y "ckn" but these signals are used by the fpga to the ddr. > > > > Has anyone the solution?. > > > > Regards > > > there are different IP cores, some use the extra feedback pin some > > dont. > > > boards that have the extra pin are better as they are easier to work > > with. > > > if you happen to have a board with no feedback pin then you need > > either use IP core > > that does not utilize the feedback, or make some workaround to the > > existing IP core > > so you can still use it. > > > Antti > > Do you know for some core without feedback?.- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - please look opb_mch_sdram DS492.PDF page 7Article: 119753
On 24 mayo, 22:37, Mark McDougall <m...@vl.com.au> wrote: > checo wrote: > > I own a Spartan 3E Starter Kit, which I plan to use for crowd- > > entertainment purposes. Since the 3-bit VGA output is way too limiting > > for my project, I am planning to add a 12-bit VGA port to my Starter > > Kit. > > Since MikeJ must be napping... ;) > > <http://home.freeuk.com/fpgaarcade/displaytest.htm> > > Regards, > > -- > Mark McDougall, Engineer > Virtual Logic Pty Ltd, <http://www.vl.com.au> > 21-25 King St, Rockdale, 2216 > Ph: +612-9599-3255 Fax: +612-9599-3266 Thanks for the heads up! The problem is I don't trust my soldering skills enough to do it myself :P, but I'll consider the option. I just don't want to risk ruining the board since having a replacement shipped over here to Mexico is not easy nor cheap nor fast (for a poor student like myself). checoArticle: 119754
Hi, Is there a quick way to constraint all IO to the same standard? The default for Spartan3 is LVCMOS25 but we want them to be LVTTL. I know I can do it by constraint one by one, but we have several hundreds pins... Thanks,Article: 119755
Symon, I agree. (Twice? I must be slacking...) To meet the IEEE/ANSI specification, there is a transmit termination. If not internal, it would be specified as external. If not shown, it still may be present. Diagrams in data sheets are often simplified. AustinArticle: 119756
"Marlboro" <ccon67@netscape.net> wrote in message news:1180106384.340327.14150@p47g2000hsd.googlegroups.com... > Hi, > > Is there a quick way to constraint all IO to the same standard? The > default for Spartan3 is LVCMOS25 but we want them to be LVTTL. I know > I can do it by constraint one by one, but we have several hundreds > pins... > > Thanks, Two things to try (there may be warnings or errors for either or both): INST * IOSTANDARD LVTTL; INST PADS(*) IOSTANDARD LVTTL; The synthesizers will sometimes allow a global IOSTANDARD default such as the syn_pad_type attribute in SynplifyPro.Article: 119757
On 25 mayo, 16:51, Antti <Antti.Luk...@googlemail.com> wrote: > On 25 Mai, 16:45, Pablo <pbantu...@gmail.com> wrote: > > > > > On 25 mayo, 12:32, Antti <Antti.Luk...@googlemail.com> wrote: > > > > On 25 Mai, 12:20, Pablo <pbantu...@gmail.com> wrote: > > > > > I have a SMT338 board. This is a FPGA module and now I want to add a > > > > DDR SDRAM to my system. I have the ucf file provided by the company > > > > but in this file I don't find ddr_feedback clock. What it means?. I > > > > suppose that this pin is neccesary, but there is no pin called > > > > "feedback" or "clk_fb" or "clk_ddr". I only see the clock signal "ck" > > > > y "ckn" but these signals are used by the fpga to the ddr. > > > > > Has anyone the solution?. > > > > > Regards > > > > there are different IP cores, some use the extra feedback pin some > > > dont. > > > > boards that have the extra pin are better as they are easier to work > > > with. > > > > if you happen to have a board with no feedback pin then you need > > > either use IP core > > > that does not utilize the feedback, or make some workaround to the > > > existing IP core > > > so you can still use it. > > > > Antti > > > Do you know for some core without feedback?.- Zitierten Text ausblenden - > > > - Zitierten Text anzeigen - > > please look > > opb_mch_sdram > connect to... what But I have to use a DDR core.Article: 119758
On May 25, 10:13 am, checo <chec...@gmail.com> wrote: > Thanks for the heads up! The problem is I don't trust my soldering > skills enough to do it myself :P, but I'll consider the option. I just > don't want to risk ruining the board since having a replacement > shipped over here to Mexico is not easy nor cheap nor fast (for a poor > student like myself). Just wire up your accessories onto a connector that _plugs in_ to the FPGA board. Either solder directly to the back of the connector pins, or use a little piece of pre-etched PC board like you can (I think even still) get from the likes of radio shack (if you have them down there). This is no more risky for the board than connecting it to a breaboard... in fact it's less risky, as the almost certainty of wires coming out of the breaboard and at some point falling against a power supply voltage is reduced - by soldering to a connector, you only have one chance to mess up, and if you get past that it should stay connected the right way. Or you could just stop owrrying and be practical... I've been known to put resistors directly into the pin sockets on the spartan 3 kit to connect to various things.Article: 119759
On 25 mayo, 07:44, Gabor <g...@alacron.com> wrote: > On May 25, 6:09 am, "Ben Jones" <ben.jo...@xilinx.com> wrote: > > I think the point is that the OP doesn't have a DAC, just three 1 or 0 > outputs from the FPGA, one to each color signal, possibly through an > external buffer. Or you could say he has "one bit" DAC's. Dithering > will work with a low-pass filter, but if there are additional pins > available it would be better to use a resistor ladder to make > a simple DAC. TFT VGA displays generally have a very narrow sampling > window (see the Analog Devices AD9888 datasheet for instance) which > is centered in the pixel time slot. This system works best when there > is no low-pass filter smearing out the beautiful contrast of the > original image. By the way, the video AC bandwidth is significantly > higher than the pixel rate in order to give the sharp edges between > pixels and flat voltage mid pixel. Generally it's important to match > the cable impedance from the DAC output to the board connector, or > if this isn't possible to reduce the length of the mis-matched portion > as much as possible, preferably to much less than a pixel time in > terms of propagation. Thank you, Gabor! My cheap multimeter says the resistance of both, the wires and the PCB traces on the board, is exactly zero. They do match! :) Now seriously, according to my calculations the "pixel length" would be 8 meters, so I guess I'm safe on that front. And yes, I understand that the spectrum of a digital signal contains very high frequency components. I was just mentioning the 25MHz number to give a (very) rough description of the signal. As for the alternate methods of displaying colors, I have already tried them with unsatisfactory results. As Gh=FCnter mentioned, changing the color value mid-pixel works only in CRT displays; and not even in all CRTs, as some would display nasty Moir=E9 patterns. Even more, I want to be able to easily convert the VGA signal to NTSC. I think this solution would make that somehow difficult. The other method I tried was using spatial and temporal dithering. I grouped pixels in 2x2 squares. Half the pixels in the group would be one color, the other half another color. If the viewer was far enough from the screen the illusion would work. To enhance this solution, I made de pixels swap positions every time the screen refreshed. For example to display "orange" the 4-pixel group would toggle between: (R is red, Y is yellow) RY YR And: YR RY With this method I raised the number of colors from 8 to 27 (a lot of combinations looked gray), which still wasn't enough. Also, it halved my resolution. So, back to the breadboard, does anyone have a prediction? Will it work? The fact that I am not being laughed at is strangely encouraging. :) -checoArticle: 119760
> I doubt you have much to worry about regarding patents on the 6502 > core architecture. First of all, as has already been pointed out, the > patent applies only to the implementation, specifically, HDL, > netlists, etc. No, patents have nothing to do with that. All that is covered by copyright. Patents deal with the ideas and concepts. Copyright issues can easily be avoided but last (virtually) for ever. Patents are difficult to avoid but expire after some time or when the patent fee is not paid. Kolja SulimmaArticle: 119761
Hello, my design consits of a Softcore, a ROM and a RAM. For the RAM I'm using a Distributed Memory (v7.1) due to its size of only 256 * 8 bit. But I can't find that RAM in the ModelSim Workspace/Memories tabsheet. The ROM is there. Is the reason that the ROM is a block memory, that would mean a distributed memory isn't recognized as memory in ModelSim? Thanks for any hint UdoArticle: 119762
On May 25, 11:23 am, checo <chec...@gmail.com> wrote: > As for the alternate methods of displaying colors, I have already > tried them with unsatisfactory results. As Gh=FCnter mentioned, changing > the color value mid-pixel works only in CRT displays; and not even in > all CRTs, as some would display nasty Moir=E9 patterns. I think if you want to try dithering and have a high-bandwidth monitor or sample-and-hold on an LCD driver, then what you need to do is put a low-pass filter on the video signal. The idea would be to flatten your dithering (hopefully at an extremely high rate) out so that from the perspective of a pixel-timescale, it's relatively flat. Of course if you low pass filter it a lot, you'll limit your ability to display crisp pixel-to-pixel transitions - you can trade off pretty pictures and blurry text, or ugly pictures and crisp text.Article: 119763
Fed wrote: >>> Fed wrote: >> That's good advice from Mike. The tools will translate your 'Z's and stuff >> into muxes anyway, so by having the seperate busses, things will be >> clearer. >> HTH, Syms. >> > Isn't that going to make it more difficult to maintain if new entities are > added in the future? Even though there are two buses instead of one, I don't have to think so hard about wiring them up. And not all additions are structural. I can add internal registers and ports to my design without adding an entity. -- Mike TreselerArticle: 119764
You can definitely send JTAG commands using ChipScope 9.1, look at the TCL interface in the ChipScope 9.1 user guide, chapter 5: http://www.xilinx.com/ise/verification/chipscope_pro_sw_cores_9_1i_ug029.pdf There is also an example tcl script in the ChipScope installation which should provide you with the basics on how to use it correctly. ChipScope also provides a tcl interpreter using the script cs_xtclsh.bat/sh but ActiveTcl can also be used (meaning you can also use wish and create a simple GUI interface). Try it out yourself from the command line: 'cd <chipscope install>/bin/<platform>' run 'cs_xtclsh csejtag_example1.tcl -usb' Matthew Hicks wrote: > Great. That sucks. You'd think Xilinx would provide a way to send JTAG > commands via iMPACT or maybe even Chipscope. Guess not. > > > ---Matthew Hicks > > >> Matthew Hicks schrieb: >> >>> I read all of the documents I could find about using the JTAG port as >>> a communications >>> interface to the FPGA and implemented my own JTAG controlled logic. >>> The >>> problem is, none of the documents that I read gave a decent solution >>> as to >>> how to get access to the JTAG chain on the PC side of things. I am >>> using >>> the Virtex II-Pro XUP board which has a USB front end to the JTAG >>> interface. >>> Is there an existing software solution available that I can use to >>> send >>> data to the user JTAG registers? If not, then is there a Xilinx API >>> that >>> I need to use to write a program to do it myself or do I need to use >>> a standard >>> USB library? Finally, once I am able to send data to the board's USB >>> interface, >>> is there a protocol that I need to follow to work with the Cypress >>> USB chip >>> or can I just send raw JTAG commands as the data payload? >>> ---Matthew Hicks >>> >> No. >> >> you can talk to almst any other interface but not to the xilinx >> platform cable as xilinx does not make the protocol info available. >> >> so, in generic talking to JTAG from PC is piece of cake. >> but if the interface is xilinx platform usb, you just cant do it, >> unless you load 3rd party firmware into the cypress chip... >> Antti >> > >Article: 119765
Alan wrote:
>
> do you have an XAPP or similar that describes that issue better?
>
>I had an X2P design a few years back that would sometimes corrupt a
>few bits of its BRAM ROMs when there were clock glitches (during DCM
>initial lock).
>
When I highlighted the difficulties in using initialized BRAM's
as ROM here on comp.arch.fpga couple of years back, Peter suggested
that I was being overdramatic [1].
Documentation:
The only documentation I know of (haven't looked for a while)
describing the faulty write enable logic is Answer Record 21870,
plus the notes in the BRAM sections of the datasheets/user guides.
Answer Record 21870 currently states the problem is limited to
V2/P and V4, but the BRAM address setup footnotes also appear in
the V5 and S3/E/A/D datasheets and/or user guides.
Neither source mentions DCM unlocks, although it is an obvious
failure mechanism to violate the address setup time.
Some of the datasheet notes provide a "sanitized" description
of the problem, that does not directly mention data corruption.
e.g. DS312-2, v3.5, page 39 :
"DESIGN NOTE:
Whenever a block RAM port is enabled (ENA or ENB = High),
all address transitions must meet the data sheet setup and
hold times with respect to the port clock (CLKA or CLKB),
as shown in Table 102, page 144.This requirement must be met
even if the RAM read output is of no interest."
Implications:
The only safe way to use an initialized BRAM is to have your DCM
startup logic hold all BRAMs disabled until the clocks are present
and stable.
If the DCMs ever unlock during operation, the only recovery
mechanism is to reconfigure the part ( or to somehow provide
BRAM re-initialization in your logic through the other BRAM port,
which defeats the whole point of initialization )
If you know ahead of time that a clock is going away, you
can deassert the BRAM enable while you switch clock sources.
Unfortunately, many of the systems I've done in the past 4-5 years
have external clocks that can come and go, without advance notice,
during operation, making this BRAM "feature" quite an annoyance.
Also of note, the use-BRAM-as-logic feature of XST is very likely
to be unsafe unless you can force the use of the enable line on the
inferred BROM.
Brian
[1] some posts from 2005 "Important BRAM Safety Tip" thread
http://groups.google.com/group/comp.arch.fpga/msg/458bb7a6301318d9
http://groups.google.com/group/comp.arch.fpga/msg/8db1a95b422f744a
http://groups.google.com/group/comp.arch.fpga/msg/67b112027f71ade8
Article: 119766Hi everybody, I have two Virtex4 FX12 Minimodules and I'd like to make them communicate eachother. These modules don't have any special transciver (RocketIO, ...) and are equipped with one PPC. The communication doesn't require high bandwidth, I need at least 30 Mbps (more it's better). The application is designed to implement a special math algorithm so the communication isn't the focus of the application and thus I cannot use all the resources for the communication. I'm using xilinx ISE and XPS to develop the application. Any suggestions on what I can I do? Protocols? Cores? Hardware issues that I should take in account? Design references from where I can start? Thanks, AndreaArticle: 119767
I read all of the documents I could find about using the JTAG port as a communications interface to the FPGA and implemented my own JTAG controlled logic. The problem is, none of the documents that I read gave a decent solution as to how to get access to the JTAG chain on the PC side of things. I am using the Virtex II-Pro XUP board which has a USB front end to the JTAG interface. Is there an existing software solution available that I can use to send data to the user JTAG registers? If not, then is there a Xilinx API that I need to use to write a program to do it myself or do I need to use a standard USB library? Finally, once I am able to send data to the board's USB interface, is there a protocol that I need to follow to work with the Cypress USB chip or can I just send raw JTAG commands as the data payload? ---Matthew HicksArticle: 119768
Hello everybody,
I m able to access/write DDR memory through a
EDK application. I also want to interface with a ASIC on the FPGA and
for that I need to pass the data read from the DDR SDRAM to specific
BRAMs in FPGA. Does anybody has any idea about how to do this? Any
tips/suggestions will be greatly helpful.
Thanks,
Koustav
Article: 119769"Andrea05" <cispa@email.it> wrote in message news:1180116308.623745.246240@g4g2000hsf.googlegroups.com... > Hi everybody, > I have two Virtex4 FX12 Minimodules and I'd like to make them > communicate eachother. > These modules don't have any special transciver (RocketIO, ...) and > are equipped with one PPC. > The communication doesn't require high bandwidth, I need at least 30 > Mbps (more it's better). > The application is designed to implement a special math algorithm so > the communication isn't the focus of the application and thus I cannot > use all the resources for the communication. > I'm using xilinx ISE and XPS to develop the application. > > Any suggestions on what I can I do? Protocols? Cores? Hardware issues > that I should take in account? Design references from where I can > start? > > Thanks, > > Andrea How abstract is your communication? If you're implementing a fixed data path, it's easy: clock and data. If you want to transfer data, exchange code segments, and post an email through a PPC-based webserver, the need for more advanced communications and protocols become attractive.Article: 119770
On 25 Mag, 20:21, "John_H" <newsgr...@johnhandwork.com> wrote: > "Andrea05" <c...@email.it> wrote in message > > news:1180116308.623745.246240@g4g2000hsf.googlegroups.com... > > > > > > > Hi everybody, > > I have two Virtex4 FX12 Minimodules and I'd like to make them > > communicate eachother. > > These modules don't have any special transciver (RocketIO, ...) and > > are equipped with one PPC. > > The communication doesn't require high bandwidth, I need at least 30 > > Mbps (more it's better). > > The application is designed to implement a special math algorithm so > > the communication isn't the focus of the application and thus I cannot > > use all the resources for the communication. > > I'm using xilinx ISE and XPS to develop the application. > > > Any suggestions on what I can I do? Protocols? Cores? Hardware issues > > that I should take in account? Design references from where I can > > start? > > > Thanks, > > > Andrea > > How abstract is your communication? > If you're implementing a fixed data path, it's easy: clock and data. > If you want to transfer data, exchange code segments, and post an email > through a PPC-based webserver, the need for more advanced communications and > protocols become attractive.- Nascondi testo tra virgolette - > > - Mostra testo tra virgolette - Yes clock and data seems to be sufficient but there isn't a peripheral for such kind of communication. All the SPI peripherals that I found are Master only for off-chip communication. Moreover at 30bps there are some electrical issues which increase the bit rate error. Have you already implemented a peripheral for this kind of job?Article: 119771
Oh yes, it rings the bell by using wild card *, but I will use it with some prefixs NET XYZ* IOSTANDARD = LVTTL; The 100% wild card " INST * " generate tons of warnings, it takes almost forever :) Thanks, On May 25, 10:33 am, "John_H" <newsgr...@johnhandwork.com> wrote: > "Marlboro" <cco...@netscape.net> wrote in message > > news:1180106384.340327.14150@p47g2000hsd.googlegroups.com... > > > Hi, > > > Is there a quick way to constraint all IO to the same standard? The > > default for Spartan3 is LVCMOS25 but we want them to be LVTTL. I know > > I can do it by constraint one by one, but we have several hundreds > > pins... > > > Thanks, > > Two things to try (there may be warnings or errors for either or both): > > INST * IOSTANDARD LVTTL; > INST PADS(*) IOSTANDARD LVTTL; > > The synthesizers will sometimes allow a global IOSTANDARD default such as > the syn_pad_type attribute in SynplifyPro.Article: 119772
Andrea, Since there are no MGT's, you will need to use some IO's from IO banks. You can use: some number of LVDS 100 ohm differential drivers to receivers (one direction only, use two sets of buses), a group of single ended IOs matched to a ribbon cable (with ground, signal, ground, dignal, this is close to 50 ohms, and can go perhaps 10 meters at the speed you need). I suggest the single ended groups, perhaps 8 wires for data, and one forwarded clock (for nine signals), and a bus like this for each direction. Clocking these 8 wires at even 10 MHz, would provide 80 Mb/s. At this slow a rate, you don't really need to clock forward, but I still would suggest it (along with the data, there is the clock on the ninth wire to strobe the other end). That way, you don't have to figure out how to get the clock off of one pcb, and get it to the other one (for a system synchronous solution). Just have registers at each end, and create your own (very simple) protocol. If a "data valid" or "data waiting" signal is needed, just use another wire. 20 wire ribbon cables are pretty common (ten signal, ten grounds). Drive the transmit end with something like LVCMOS 8 mA FAST, which is very close to 50 ohms, and there should be no overshoot, or undershoot, and the Signal integrity will be good. If that is still too strong, 6 mA, and even 4 mA drivers can be selected. The only reason a protocol is required with the MGTs (like aurora: http://www.xilinx.com/products/design_resources/conn_central/grouping/aurora.htm is that designers need huge bandwidth, and in order to re-synchronize multiple MGTs (channel bonding), a layer is required to manage all that stuff. With a simple parallel interface, you pretty much only need to implement what you need. To connect these buses to the 405PPC, you will either have to interface to the PLB bus, or create an input and output port that is connected to the 405PPC. Depending on how fancy you want this to be, it could be as simple as input and output instructions (you create the protocol in software), or as fancy as a FIFO buffer with DMA into memory mapped into the 405PPC data memory (the protocol commonly used here is referred to as "flags placed under a rock" which is a reference to one processor just waits for a memory location to change, which tells it that the data it is waiting for is all there, and ready to be read from memory...the transmitting processor sends all the data, and sets the flag to tell the receiving processor to pick up the data. Lots of choices here, and not many "standards" as the task is very simple, and folks tend to use only what logic they need to in order to do the job. Once you pop up to MGTs, there are many more choices, only because there are more complex interfaces: ethernet, fibre channel, PCIe, etc..... If you don't need fibre channel, then you don't need media access controllers (MAC), etc. http://www.xilinx.com/products/design_resources/conn_central/solution_kits/index.htm AustinArticle: 119773
Matthew Hicks schrieb: > I read all of the documents I could find about using the JTAG port as a communications > interface to the FPGA and implemented my own JTAG controlled logic. The > problem is, none of the documents that I read gave a decent solution as to > how to get access to the JTAG chain on the PC side of things. I am using > the Virtex II-Pro XUP board which has a USB front end to the JTAG interface. > Is there an existing software solution available that I can use to send > data to the user JTAG registers? If not, then is there a Xilinx API that > I need to use to write a program to do it myself or do I need to use a standard > USB library? Finally, once I am able to send data to the board's USB interface, > is there a protocol that I need to follow to work with the Cypress USB chip > or can I just send raw JTAG commands as the data payload? > > > ---Matthew Hicks No. you can talk to almst any other interface but not to the xilinx platform cable as xilinx does not make the protocol info available. so, in generic talking to JTAG from PC is piece of cake. but if the interface is xilinx platform usb, you just cant do it, unless you load 3rd party firmware into the cypress chip... AnttiArticle: 119774
On May 25, 12:43 pm, Mike Treseler <mike_trese...@comcast.net> wrote: > Fed wrote: > >>> Fed wrote: > >> That's good advice from Mike. The tools will translate your 'Z's and stuff > >> into muxes anyway, so by having the seperate busses, things will be > >> clearer. > >> HTH, Syms. > > > Isn't that going to make it more difficult to maintain if new entities are > > added in the future? > > Even though there are two buses instead of one, > I don't have to think so hard about wiring them up. > And not all additions are structural. > I can add internal registers and ports to my > design without adding an entity. > > -- Mike Treseler If you do not have multiple devices on the bus writing data to multiple other devices (usually if there is only one master), then using two buses (read & write buses) eliminates the false timing paths that can occur with a single bus (originating from one slave and arriving at another), and is just as easy to wire up. Otherwise, having two buses is harder. Andy
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