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
Dear I could not resove this problem. UNISIM and XILINXCORELIB are properly mapped to Modelsim. The thing is that The VHDL files "in Pcore directory" contain following: (BRAMs are instantiated in the VHDL.) -------------------------------------- -- pragma translate_off library VIRTEX2; use VIRTEX2.all; -- pragma translate_on -------------------------------------- When I try "do system.do", error occurred "Virtex2 library not found". When I comment the "Virtex2 library declaration" and I try "do system.do", no error and no warning occurred. -------------------------------------- -- pragma translate_off --library VIRTEX2; --use VIRTEX2.all; -- pragma translate_on -------------------------------------- Problem is that When I try "vcom -work work testbench.vhd", then following warning occurs. ----------------------- Warning: Component instance "ramx32 : ramb16_s36_s36" is not bound. ----------------------- This means that BRAM block is disappeared. As a result, I do not see any signal toggling in the waveform in Modelsim. My question is that What does the following mean? How can we find the library "VIRTEX2" and map? -------------------------------------- -- pragma translate_off library VIRTEX2; use VIRTEX2.all; -- pragma translate_on -------------------------------------- Thank you for reply in advance.Article: 126151
Thanks for trying to help, but it didn't work. I updated a simple piece of hardware to use a different bit to drive an LED (1/2 as fast blinking), saved, hit the refresh repositories button, after implementation... same old results. ---Matthew Hicks > Matthew Hicks wrote: > >> When working with custom peripherals in EDK, is there a better way to >> make sure changes to the hardware design take effect than trying to >> re-import the peripheral? I spent several hours last night debugging >> a design that was failing because EDK wasn't loading the updated >> hardware design (just logic, no change in external ports). I made >> sure it did a fresh synth+impl run every time, but somehow the >> functionality never changed even though the hw design did. Even >> after removing the instance and re-importing and re-connecting it. I >> finally got it to work by creating a completely new hw design (in >> name only) with the same logical functionality and using it in place >> of the previous block. >> > I think Project->Rescan User Repositories will solve your problem. >Article: 126152
EEngineer wrote: > On Nov 15, 9:41 am, Andrew Ganger <Andre...@yahoo.co.uk> wrote: > >>>Two write ports sounds dangerous :) - but classic RISC devices >>>might need 3 read ports, and one write port >> >>>Rd = Ra OPERAND Rb OPERAND Rc >> >>>one fast/simple idea I had for emulating this on dualport memory is to >>>use two blocks and simply parallel the one write port >>>- so the two have identical info, and would actually give 4 read ports >> >>>Yes, it's a little redundant, but easy to implement, and the RegFiles >>>are small anyway. >> >>Yeah, it might be dangerous, but in my case I would need two write ports ;). >> >>So yeah, this sounds like a good idea. So I would have two RAM blocks >>each with two read, and two write ports. In this case I write the result >>back simultanlously in both register files. Looks like a good idea for >>a first evaluation! >> >>Thanks! > > > Probelem with this is what if more than two registers that need to be > written are located at the same RAM block! I am using 8 parallel > blocks in my design as I am writting 8 memory locations at a time but > I am sure that all 8 memory locations belong to different RAM block. Err, no?. What you do is keep the 4 read poert separate, and parallel each side's write ports - so you always write to TWO locations at once. You have consumed block ram, for the sake of simplicity and speed. You always write-before-using, both blocks have identical contents. The only danger case is if the SW writes to (eg) R13 and R13, which could be trapped in HW, and/or in the assembler. -jgArticle: 126153
In news:e5335b73-f4dc-476a-8945-c2b3ff99a53e@b15g2000hsa.googlegroups.com timestamped Thu, 15 Nov 2007 10:27:24 -0800 (PST), Pasacco <pasacco@gmail.com> posted: |----------------------------------------------------------------------| |"[..] | | | |My question is that | | | |What does the following mean? | |How can we find the library "VIRTEX2" and map? | |-------------------------------------- | |-- pragma translate_off | |library VIRTEX2; | |use VIRTEX2.all; | |-- pragma translate_on | |-------------------------------------- | | | |Thank you for reply in advance." | |----------------------------------------------------------------------| -- pragma translate_off is to inform Synopsys to not to try to synthesize the following code before -- pragma translate_on. The intention is to allow code which can be e.g. simulated but which is not to be synthesized, but you are experiencing a problem in getting the simulation to run. Is it extremely important to you to have a precise model of the BRAM? Would it be acceptable to substitute the synthesized Virtex2's BRAMs with a functional generic RAM in the simulation?Article: 126154
> -- pragma translate_off is to inform Synopsys to not to try to > synthesize the following code before -- pragma translate_on. The > intention is to allow code which can be e.g. simulated but which is > not to be synthesized, but you are experiencing a problem in getting > the simulation to run. Is it extremely important to you to have a > precise model of the BRAM? Would it be acceptable to substitute the > synthesized Virtex2's BRAMs with a functional generic RAM in the simulation? When I simulate, I do not see any signal toggling in the waveform, because BRAMs are unconnected. Actually the "pcores" are provided by a vendor. I could modify the VHDL code, but it is too time consuming. According to your reply, there might exist "specific Virtex2" library for the BRAMs. Are there any way to find the Virtex2 library, to simulate with Modelsim? Thank you for reply.Article: 126155
Matthew Hicks schrieb: > When working with custom peripherals in EDK, is there a better way to > make sure changes to the hardware design take effect than trying to > re-import the peripheral? I spent several hours last night debugging a > design that was failing because EDK wasn't loading the updated hardware > design (just logic, no change in external ports). I made sure it did a > fresh synth+impl run every time, but somehow the functionality never > changed even though the hw design did. Even after removing the instance > and re-importing and re-connecting it. I finally got it to work by > creating a completely new hw design (in name only) with the same logical > functionality and using it in place of the previous block. > > > ---Matthew Hicks > > hello Matthew, you can for development of IP-Cores set in the .mpd file the OPTION CORE_STATE to "DEVELOPMENT". OPTION CORE_STATE = DEVELOPMENT See also in the EDK doc directory the Manual Platform Specification Format Reference Manual (psf_rm.pdf) Page 42 (EDK 8.2 Version). The core will every time synthesized if you change any bit. Best regards, DanielArticle: 126156
Thank you for reply. When I simulate, I do not see any signal toggling in the waveform, because BRAMs are unconnected. Actually the "pcores" are provided by a vendor. I could modify the VHDL code, but it is too time consuming. According to your reply, there might exist "specific Virtex2" library for the BRAMs. Name of the BRAM primitive is "ram_dp". Are there any way to find the Virtex2 library, to simulate with Modelsim? Maybe my problem is not a "library problem".Article: 126157
Matthew Hicks wrote: > When working with custom peripherals in EDK, is there a better way to make > sure changes to the hardware design take effect than trying to re-import > the peripheral? I spent several hours last night debugging a design that > was failing because EDK wasn't loading the updated hardware design (just > logic, no change in external ports). I made sure it did a fresh synth+impl > run every time, but somehow the functionality never changed even though the > hw design did. Even after removing the instance and re-importing and re-connecting > it. I finally got it to work by creating a completely new hw design (in > name only) with the same logical functionality and using it in place of the > previous block. Remove the corresponding generated .ngc files, including the ones in the cache directory: rm implementation/my_wrapper.ngc rm implementation/cache/my_wrapper.ngc (rm is a Linux command, in case you are on Windows) When you rerun the synthesis, it will rebuild the files from the new code.Article: 126158
Pasacco wrote: > Thank you for reply. > > When I simulate, I do not see any signal toggling in the waveform, > because BRAMs are unconnected. > > Actually the "pcores" are provided by a vendor. > I could modify the VHDL code, but it is too time consuming. > According to your reply, there might exist "specific Virtex2" library > for the BRAMs. > > Name of the BRAM primitive is "ram_dp". I am a little puzzled by that statement. Earlier you said: > When I try "vcom -work work testbench.vhd", then following warning > occurs. > > ----------------------- > Warning: Component instance "ramx32 : ramb16_s36_s36" is not bound. > ----------------------- In that case, the BRAM primitive name is ramb16_s36_s36. That primitive is a standard one available in the Xilinx unisim library. > > Are there any way to find the Virtex2 library, to simulate with > Modelsim? > > Maybe my problem is not a "library problem". Yes, it is a library problem. Your vendor appears to be doing things in a weird way, and a bit more info is needed to figure out what they are doing. Show all the library declarations in the file (not just the virtex2 ones). If there is a component declaration for the bram at the beginning of the architecture (that is, before the 'begin' statement), show that. Show the component instantiation of the bram within the body of the architecture. If there are multiple instantiations, just show one.Article: 126159
On Nov 15, 4:08 am, Andrew FPGA <andrew.newsgr...@gmail.com> wrote: > Hi, > This is an embarrassing question to be asking - how does one attach > signals from the edk design to the chipscope ILA? When I sit down at > my desk to debug with a benchtop logic analyser, the first thing I do > is attach the probes to the pcb - I kinda expected it would be simple > and straightforward with chipscope pro also? > > I'm using EDK 9.1i, sp3. I used the debug->debug config menu and > selected an ILA. Its easy to select signals and add them to Trig0. But > if I want the trigger and data capture signals to be different, where > and how do I attach signals in my design to the data capture port on > the ILA? > > (I have limited resources remaining on my FPGA and I only need a few > simple signals connected to the trigger input, but I want a wider > selection of signals captured in the trace buffer) > > I tried manually editing the ILA component in the .mhs file, by adding > the entry below: > > PORT DATA = > EthInterfaceTimestamp_0_rx_dv_falling_edge_r_to_chipscope_ila_0 & > EthInterfaceTimestamp_0_rx_dv_rising_edge_r_to_chipscope_ila_0 & > EthInterfaceTimestamp_0_tx_en_falling_edge_r_to_chipscope_ila_0 & > EthInterfaceTimestamp_0_tx_en_rising_edge_r_to_chipscope_ila_0 & > EthInterfaceTimestamp_0_timestamp_to_chipscope_ila_0 > > Which caused edk to crash...Is editing the .mhs file ok? > > Regards > Andrew Hi Andrew, It is very straightforward, you have one data port and one trig port on the chipscope IP in EDK. Then you have to configure the IP by right- clicking the IP and choose configure IP. You have to set the data and trigger port widths. You should only edit the mhs file if your'e certain about the syntax. Regards, RogerArticle: 126160
Following your advice, I edited the .mpd file for the core to include the "CORE_STATE" option. After going back into EDK and refreshing repositories, the .mpd change was reflected in EDK. After going through the complete implementation process, everything works as it should. Thanks for this tip (I wish it would be default behavior, or more evident that this option exists during import), you saved me many more hours of uneeded hassel. Also, thanks for the reference where I can read-up more on other options. ---Matthew Hicks > Matthew Hicks schrieb: > >> When working with custom peripherals in EDK, is there a better way to >> make sure changes to the hardware design take effect than trying to >> re-import the peripheral? I spent several hours last night debugging >> a design that was failing because EDK wasn't loading the updated >> hardware design (just logic, no change in external ports). I made >> sure it did a fresh synth+impl run every time, but somehow the >> functionality never changed even though the hw design did. Even >> after removing the instance and re-importing and re-connecting it. I >> finally got it to work by creating a completely new hw design (in >> name only) with the same logical functionality and using it in place >> of the previous block. >> >> ---Matthew Hicks >> > hello Matthew, > you can for development of IP-Cores set in the .mpd file the OPTION > CORE_STATE to "DEVELOPMENT". > OPTION CORE_STATE = DEVELOPMENT > > See also in the EDK doc directory the Manual Platform Specification > Format Reference Manual (psf_rm.pdf) Page 42 (EDK 8.2 Version). > > The core will every time synthesized if you change any bit. > > Best regards, > DanielArticle: 126161
Thanks, this also works. ---Matthew Hicks > Matthew Hicks wrote: > >> When working with custom peripherals in EDK, is there a better way to >> make sure changes to the hardware design take effect than trying to >> re-import the peripheral? I spent several hours last night debugging >> a design that was failing because EDK wasn't loading the updated >> hardware design (just logic, no change in external ports). I made >> sure it did a fresh synth+impl run every time, but somehow the >> functionality never changed even though the hw design did. Even >> after removing the instance and re-importing and re-connecting it. I >> finally got it to work by creating a completely new hw design (in >> name only) with the same logical functionality and using it in place >> of the previous block. >> > Remove the corresponding generated .ngc files, including the ones in > the > cache directory: > rm implementation/my_wrapper.ngc > rm implementation/cache/my_wrapper.ngc > (rm is a Linux command, in case you are on Windows) > When you rerun the synthesis, it will rebuild the files from the new > code. >Article: 126162
On Nov 15, 2:41 am, Herbert Kleebauer <k...@unibwm.de> wrote: > - The essential drawback is the missing back annotation of the simulation > results into the schematic. This is like debugging software with print > statements instead of a source code debugger. A few years ago I tested > an older version (I think it was ISI 2.1) and there at least you could > attach probes in the schematic to display the states of signals. > This also was only a makeshift, but better than nothing. Now that's funny! You don't like HDL, but a source level (text) debugger is a better idea? Just how do you do a simulation without some sort of textual stimulation (or with an hdl, at least you can have behavioral stimulation)? Please don't tell me you click on a wire and start typing ones and zeroes? I think the bottom line is that graphics show structure better, text shows behavior better. I use RTL viewers (synplicity and quartus are really good) to extract the structural graphics from my HDL source if/ when I need it (presentations, reviews, etc.) It is a lot easier to do that than to specify (or debug) behavior from graphics. I'm old enough have done a lot of ABEL/CUPL for PALs, and schematic capture for xc2000/xc3000 designs, and I hated VHDL for a long time. My old boss hung up a quote of mine about trying to design SW by drawing pictures, while HW design was hell-bent-for-leather, headed the other way. Previous poster notwithstanding, I used GED (precursor to Concept) to build wonderful, intelligently parameterizable functional blocks that could be interconnected in an easily understood, structual way. Unless I needed to design a state machine... That's when I started to design behaviorally, instead of structurally. Now, design structure is mostly about managing behavioral complexity, and a only little about managing physical complexity. Once you make that thought shift, it's gravy from there on. So where is the future of "schematic capture"? Just like in board level design, when you are designing structurally with pre- manufactured blocks, and just hooking them up with wires, that's where graphical design entry makes sense. We're probably headed back there with FPGA's, what with increased use of IP, where the bulk of our "design" is hooking up pre-designed blocks of circuitry. So we dive into a custom block every now and then to use HDL to design a custom behavioral translator to make block A talk to block B... BTW, I've used Concept and Capture (Orcad) for board design, and trust me, Concept is WAY ahead of Capture. They keep adding features from Concept into Capture though, so one of these days... Alright, I've ambled on enough. AndyArticle: 126163
On Nov 15, 3:14 am, "zlotawy" <paraliczb@NO_SPAM_orange.pl> wrote: > Uzytkownik "Peter Alfke" <pe...@xilinx.com> napisal w wiadomoscinews:1195079702.949034.33320@e9g2000prf.googlegroups.com... > > >A large asynchronous FIFO will always most efficiently be implemented > > in a dual-ported BlockRAM, and have a width of 1, 2, 4, 9, 18, or 36 > > bits. If you need a different width, just pad it to the higher value. > > Also Din and Dout have the same width. > > Anything different will get very complicated... > > The main problem in the design of asynchronous (2-clock) FIFOs is the > > reliable generation of the Full and Empty flags at high clock rates. > > hmmm... which clock sets flags? > > And what if two clocks are the same? Then should I change type of fifo (one > clock)? > > zlotawy If both clocks are the same, the design becomes a trivial synchronous state machine. Only fast asynchronous FIFO controllers are tricky and somewhat controversial, due to the metastable risk and its avoidance. Peter AlfkeArticle: 126164
Hi Roger, Thanks for the info, but following your suggestion does not appear to be any different than going to the menu Debug->debug configuration and selecting ila0. Sure you can set the trigger port width and data width. You can also add signals to the Trigger input. But how do I add signals to the DATA ila input? I can use the system assembly view with ports filter is see the ILA ports. I can see the data port, but the connection drop down list only allows me to connect one signal at a time. Of course I want to connect several different signals to the Ila Data port but can't see how? > It is very straightforward, you have one data port and one trig port > on the chipscope IP in EDK. Yes it describes this in the documentation, but it is quite unclear as to how one connects signals in the design to the Data port. > Then you have to configure the IP by right- > clicking the IP and choose configure IP. You have to set the data and > trigger port widths. You should only edit the mhs file if your'e > certain about the syntax. Yeah, and I don't know the syntax for the Data port, nor have I been able to find it. :(Article: 126165
On 2007-11-15, JimboD2@gmail.com <JimboD2@gmail.com> wrote: > > Using chipscope, i've observed that the host bus to the hard MAC is > functioning during read/writes for emac0, but not when addressing > emac1. It seems that the plb_temac for emac1 does not initiate a > transfer on the host bus. You probably forgot to set C_TEMAC_INST in the second PLB temac (in addition to C_TEMAC_BOTH_USED). I hear there is tcl code to catch this in Xilinx's code, but it's commented out... -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 126166
Has anyone worked with the Lattice Semiconductor ECP2M series of FPGA? Were the parts easy to get? Also, how is the ispLever design software from Lattice? I've worked exclusively with Xilinx FPGAs and am looking for some feedback about what else is out there. My particular interest developed in the Lattice ECP2M because I need a FPGA/SERDES combo and the price for the ECP2M seems unbelievable compared to their competitor's equivalent FPGAs. So, I'm thinking something must be wrong? Thanks, ColinArticle: 126167
"Colin Hankins" <Colin.Hankins@touit.com> wrote in message news:A35%i.17632$pr6.16558@newsfe06.phx... > Has anyone worked with the Lattice Semiconductor ECP2M series of FPGA? > Were the parts easy to get? Also, how is the ispLever design software from > Lattice? > > I've worked exclusively with Xilinx FPGAs and am looking for some feedback > about what else is out there. My particular interest developed in the > Lattice ECP2M because I need a FPGA/SERDES combo and the price for the > ECP2M seems unbelievable compared to their competitor's equivalent FPGAs. > So, I'm thinking something must be wrong? > > Thanks, > Colin I want to work with the parts but have yet to get the design start with Lattice because of unrelated issues. My personal belief is that they targeted the right mix of features at the right time to hit big holes in the competitions' low-cost portfolios. Given reasonable cost of dedicated high-speed devices out there, I just don't understand why SerDes *should* cost as much as is implied by other FPGA vendors. Another aspect: Lattice is probably hungrier than the big guys to get those design wins to establish themselves as a strong player. I hope we both get a chance to work with the ECP2Ms. - John_HArticle: 126168
I have a V4FX based product and I'd like to have a DSP coprocessor to go with the the powerpc that handles my operating system. Are there TI c54x or c3x soft cores out there that could be compiled into a xilinx fpga? Could be anyone's dsp, I suppose, so long as it has a large existing code base and mature tools. Also is microblaze an option? Can it do significant DSP? Thanks, ClarkArticle: 126169
You still are not adding the Library stuff when you are calling "vcom" vcom -L XILINXCORELIB_VER -L UNISIM work.testbench Hope this helps. -- parag On Nov 15, 12:27 pm, Pasacco <pasa...@gmail.com> wrote: > Dear > I could not resove this problem. > > UNISIM and XILINXCORELIB are properly mapped to Modelsim. > > The thing is that > > The VHDL files "in Pcore directory" contain following: > (BRAMs are instantiated in the VHDL.) > > -------------------------------------- > -- pragma translate_off > library VIRTEX2; > use VIRTEX2.all; > -- pragma translate_on > -------------------------------------- > > When I try "do system.do", error occurred "Virtex2 library not found". > > When I comment the "Virtex2 library declaration" and I try "do > system.do", > no error and no warning occurred. > > -------------------------------------- > -- pragma translate_off > --library VIRTEX2; > --use VIRTEX2.all; > -- pragma translate_on > -------------------------------------- > > Problem is that > > When I try "vcom -work work testbench.vhd", then following warning > occurs. > > ----------------------- > Warning: Component instance "ramx32 : ramb16_s36_s36" is not bound. > ----------------------- > > This means that BRAM block is disappeared. > > As a result, I do not see any signal toggling in the waveform in > Modelsim. > > My question is that > > What does the following mean? > How can we find the library "VIRTEX2" and map? > -------------------------------------- > -- pragma translate_off > library VIRTEX2; > use VIRTEX2.all; > -- pragma translate_on > -------------------------------------- > > Thank you for reply in advance.Article: 126170
HI Colin, A couple of weeks ago, one of the local FAE's told me that only the biggest device/package (ECP2M100-F1152) is not available in production. This means that you should be able to get parts quickly. I have personally worked with ECP2M20-F256 on a video board (HD/SD-SDI) and I haven't encountered big issues. I got it to work in some 2 weeks time. And yes you are right, the price of the ECP2M family vs. competitor's equivalent IS incredible. The price was cut by two. Success with your implementation. Luc On Thu, 15 Nov 2007 15:59:22 -0800, "Colin Hankins" <Colin.Hankins@touit.com> wrote: >Has anyone worked with the Lattice Semiconductor ECP2M series of FPGA? Were >the parts easy to get? Also, how is the ispLever design software from >Lattice? > >I've worked exclusively with Xilinx FPGAs and am looking for some feedback >about what else is out there. My particular interest developed in the >Lattice ECP2M because I need a FPGA/SERDES combo and the price for the ECP2M >seems unbelievable compared to their competitor's equivalent FPGAs. So, I'm >thinking something must be wrong? > >Thanks, >Colin >Article: 126171
"Brian Drummond" <brian_drummond@btconnect.com> wrote in message news:lrgoj3d81f2jgs5jtd1rc037b9qmugn89v@4ax.com... > On Wed, 14 Nov 2007 18:31:15 -0800 (PST), Amit <amit.kohan@gmail.com> > wrote: > >>On Nov 12, 8:57 am, Ray Andraka <r...@andraka.com> wrote: >>Hi Ray, > >>Thank your response. what is your webiste's domain? > > I think I'd try www.andraka.com just to see what happened... > > - Brian I firmly believe that there needs to be some sort of universally-accepted occupational guidance test put into place. Here is a candidate for the first and only question: 1 - Find Ray Andraka's website on your own. If one fails this test then that person would be forced to look deeply into a mirror and would be strongly encouraged to consider a more menial occupation. BobArticle: 126172
On 2007-11-13, Andy <jonesandy@comcast.net> wrote: > I've been wishing for user defined modes for record type ports (or > procedure arguments), used in lieu of in, out or inout, that would > allow you to specify the mode of each individual element. If only we > could do something like: > > type bus_type is record > data : std_logic_vector(31 downto 0); > ack : std_logic; > ... > end record; > mode slave of bus_type is (data => inout; ack => out; others => in); > mode master of bus_type is (data => inout; ack | clk | rst => in; > others => out); If you aren't too attached to VHDL you could look at SystemVerilog which has exactly this functionality. Keywords to look for are "interface" and "modport". /AndreasArticle: 126173
On 14 Nov., 18:34, Jan Pech <n...@spam.please> wrote: > Hello all, > > I would like to use the USR_ACCESS_VIRTEX4 primitive to access an > additional bitstream stored in a config flash. The situation is > following: > * I have a master FPGA (Virtex-4FX) and a slave FPGA (Spartan-3A). The > slave FPGA is located on an additional board and it is NOT daisy-chained > with the master one. > * Master FPGA gets configured out of platform flash in master serial > mode. > * I need to configure even the slave FPGA. The only non-volatile source > of its configuration data is the platform flash connected to the master > FPGA. > > I used STARTUP_VIRTEX4 primitive to take control over the CCLK and DONE > signals. While generating bitstream I used the "-g DONE_cycle:KEEP" > option. From my measurements of the interface between flash and > Virtex-4, this part of the design works fine. I fully control the > signals, DONE does not go high anywhere in the middle, and flash sends > me additional bitstream data. > > To access additional bitstream I instantiated the USR_ACCESS_VIRTEX4 > primitive, but here is the problem. Even though I see the data on the > DIN input of the Virtex-4, the DATAVALID output of the > USR_ACCESS_VIRTEX4 primitive never goes high. So that I am unable to > reach this data inside the Virtex-4 FPGA. > > The Virtex-4 Libraries Guide for HDL Design says: The PROM should > contain a packet of data with the USR_ACCESS register as the target. I > generated my PROM file using iMPACT simply putting two bitstreams into > single MCS file what is probably wrong. I think my MCS should contain > normal master FPGA bitstream followed by the slave FPGA bitsream with > target set to USR_ACCESS. Is there any way how to set target for the > second bitsream in MCS to USR_ACCESS so that I could access it from my > master FPGA? > > If I am trying to do something impossible, is there another approach how > read slave configuration data from platform flash using master FPGA? I > cannot do it simply controlling flash pins, as they are not connected to > IO pins of the FPGA but to dedicated configuration pins only. > > Thanks for advices, > Jan no no no :) what you want is doable ok, but not with the tools provided by xilinx . you need 1) your own bit file merge tool that converts and inserts specially formatted bitstream into master bitstream 2) your own USR_ACCESS_TO_SERCONFIG gateway IP-core that you compile into the master FPGA please look at ultracontroller reference designs, xilinx uses this (very similar method) to load the PPC memories they add the info into master bitstream and use usr_access connected JTAG master ip core AnttiArticle: 126174
Hi there, I am currently designing an FPGA board, featuring two Xilinx Virtex-4 FPGAs. I've already posted another question concerning a correct JTAG chain implementation a few days ago and gained pretty good response. But some problems remain... although on another topic: I'll be using the Xilinx Virtex-4 FX series FPGAs featuring the high-speed MGTs. The MGTs are located in two rows on each FPGA, each requiring their own MGT reference clock, i.e. four reference clock inputs have to be fed altogether plus at least one additional clock input for the core logic per FPGA. Because the FPGAs have to exchange data synchronously (via the standard GPIOs) I thought about using the same reference clocks for both FPGA and making them the same as the MGT reference. Unfortunately that leads to a clock signal that has to be distributed to at least 6 FPGA clock inputs. I don't think that a regular low-jitter clock device (and it HAS to be low-jitter as for the reference for the MGTs) can drive 6 inputs over several centimeters. I already used the ICS843020 clock synthesizer in several other projects and wanted to use it again. Reason for the ICS is that it features a programmable output frequency in the range of 35 - 700 MHz. Problem is, the ICS843020 has only two outputs. The Epson EG2121CA device that is proposed in the Virtex-4 MGT user guide is not suitable because these devices are restricted to one fixed frequency. Maybe a clock buffer or multi-output clock distribution device is the solution here, but I am afraid every additional device in the clock network would introduce additional jitter which is the most critical aspect in this application. Therefore I woul prefer a solution without those kind of devices... if possible. Has anyone ever had a similar problem and knows about an adequate solution? Any help (if possible) is much appreciated. Thanks! Regards Toni
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