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 am interested in using the Xilinx 10/100 Ethernet solution supported in their Spartan3 eveluation kit. I have a JTAG based flash PROM XCF02S connected to the Spartan3. I would like to know best way to do the In System Programming of this JTAG based PROM over the ethernet. The Xilinx reference design for the 10/100 ethernet uses Microblaze. We were thinking about putting down GPIO pins from the FPGA to the JTAG based PROM so that it can be programmed over the Ethernet. If there is already a ready made solution for this then that will help us. Thanks. CPArticle: 130851
On Mar 26, 4:24=A0am, Philip Potter <p...@doc.ic.ac.uk> wrote: > ahosyney wrote: > > [Powerestimationusing XPower and ModelSim] > > > To Clarify this I started with an array size of 10 integers, this > > array requires 887 clock cycles to be sorted and the total estimated > >powerconsumption was around 488.65 mW. When I increased the array > > size to 20 integers (which requires 3069 clock cycles to be sorted) > > the estimatedpowerconsumption was 492.28mW with increase of about > > 3.5 mW. When I increased the number of integers to 40 (11298 clock > > cycles are needed to sort that), thepowerconsumption just increased > > by around 2mW to be 494.29mW. When I raised the number of integers to > > be 80 (43280 clock cycles to be sorted), thepowerconsumption was > > reduced to 493mW. So it seems that the activities stored in the VCD > > file are not affecting thepowerestimationas I expected. > > Why would you expect thepowerto be higher? Remember thatpoweris > energy-per-second. I would expect the 20 integer case to require much > the samepoweras the 10 integer case, but because it takes 3069/887 > times longer, it would use 3069/887 times more energy. A MicroBlaze > doesn't consume more energy per instruction or energy per second just > because the overall problem size is bigger! > > Note that had you used a different solution than a MicroBlaze or > PowerPC, for example a parallel solution with greater parallelism for > larger problem size, then it is entirely possible that thepower > consumption would increase for larger problem sizes, while the time to > solve the problem remained constant. Thank you for your reply. I understand what you say. I excpected the power to vary with much more amount than just the 2 mW. I'm using the same array in all the test, so the number of swaps required will vary from test to the other (data has changed), which should result in some change in the power required to access the memory. Actually after installing ISE 10.1 I got a variation of about 20mW. It seems that XPowr 9.2i has a problem loading VCD files.Article: 130852
I tried to reflash my SPI FLASH memory with the DOS program supplied by XILINX (I don't remember the name of the DOS program) and get an error saying the synchronization word is missing. How can I include this synchronization word?Article: 130853
On Apr 3, 3:10 am, Antti <Antti.Luk...@googlemail.com> wrote: > PS, I was thinking that 10.1 is not suggested for ML505, but when i > just NOW opened the ml505 support PDFs they list ISE 10.1 and EDK 10.1 > > Xilinx, if you say ML505 is to be used with EDK 10.1 then PLEASE fix > the revup or make the 10.1 version of EDK ref design available! > > I dont want spend weeks to troubleshoot why xilinx ML505 ref design > doesnt work with EDK 10.1 FWIW, our Avnet FAE told us that the 10.1 EDK was exactly the same as the 9.2 EDK. It was given a rev bump so that Xilinx wouldn't get the usual howls about the EDK shipping months after the ISE tools. -aArticle: 130854
Craig wrote: <snip> I recieved a phone call from someone reading my last post. They were not very happy about my authorized channel statement. I provide this information for peice of mind. If you buy parts from independent distributors that is not my issue. If the independent Disti is legitimately buying for an authorized Xilinx channel and can demonstrate a clean line of custody you may be Okay. It is your own comfort level with that transaction. However, some folks choose to buy parts from the broker market. Well, the problem is this board was originally designed with a part I could get from an authorized distributor, I believe for about $15. (I could be mis-remembering this price.) Now, I am faced with $60 price and multi-hundred piece minimums from all auth. dists! I am a small manufacturer, just trying to stave off disaster while I'm redesigning with a newer part. So, I am caught between a rock and a hard place. JonArticle: 130855
On Apr 3, 5:16=A0am, maverick <sheikh.m.far...@gmail.com> wrote: > Hi, > I need to know how can I prohibit a configuration file from being > downloaded on a similar FPGA device. For example, if I have two > similar FPGA boards and I want only one FPGA board to be successfully > programmed with the configuration file whereas if the same > configuration file is downloaded on the other FPGA board, it should > not get programmed. The target device is Virtex II Pro. I know there > is this encryption feature available there for Virtex II and VIrtex II > Pro devices but I am talking about the environment where the FPGAs > will be programmed on startup through host application through PCI and > there is no human intervention for programming the FPGA (or providing > the encryption key). Here is the whole concept. I have a PC system > where a PCI based 'COTS' FPGA card is installed. On startup, my > application programs the FPGA board with the configuration file. > However, if another similar FPGA board is installed in the same PC > system, the application should (somehow) not programm the FPGA or the > FPGA fails to get programmed successfully. I looked into the Device > IDCODE thing but I came to know that the IDCODEs are the same for all > FPGAs belonging to a particular family for example Spartan 3 sc3s1000 > FPGA parts will have the same IDCODE. (had it been unique, I would > have stored the IDCODE in my application and on finding a different > IDCODE, I would have aborted the programming device sequence) > > I hope I have mentioned my problem statement clearly........ > > Any suggestion......... > > Farhan Since you mention that you are loading the bitfile over the PCI bus, I am assuming that the FPGA is on the PCI card, as opposed to a daugher card. Is this correct? If so, you could use the PCI configuration space to tell the cards appart. If you also know what board the bitfile is for, then the drive could check to make sure that the board and bitfile versions match, and refuse to load the bit file if it does not. Regards, John McCaskill www.FasterTechnology.comArticle: 130856
> > or you want to implement a system with PCB footprint 6 by 6 mm? > you could use > AGL060 6x6 mm > winbond quad outserial flash 6x5 mm > > so if double mounted the FPGA and serial flash take 6by6 + caps, > but there is no softcore that could fit and make sense. > adding a 2x3 mm MCU may also be overkill in some times But a comparable MCU is always cheaper, both in development and production. A serial design does also invalidate many of the advantages of programmable logic - eg. latency, throughput and so on.Article: 130857
Years ago I thought about using a serial design to implement a CPU in a GAL 16V8 or 20V8. My idea was to map all registers to memory and to use a 64kbit DRAM as a 256x8 memory that is accessed bit wise. Refresh would have been automatically provided by cycling through the registers. Unfortunately that design never got anywhere. The main issues where that all the flipflops were eaten up by state counters and the design got horribly complex. The ALU design itself was of course negligible.Article: 130858
"Jeff Cunningham" <jcc@sover.net> wrote in message news:47f4e09f$0$19850$4d3efbfe@news.sover.net... > Brian Drummond wrote: >>>> >>> Rather than actually answer the question, can I suggest that you infer >>> BRAM rather than go through that complicated process? As a bonus, >>> inferred BRAM simulates much faster. You would infer BRAM something >>> like: >> >> Err, not necessarily a good idea. >> >> For example, inferring a ROM wide enough to need both data buses and the >> parity >> bits can cause three BRAMs to be used instead of one; to be fair, ISE 9.2 >> improved on 7.1 in my test case, only inferring twice as many BRAMS as >> necessary. >> >> However, initialising the ROM data using functions caused elaboration to >> take >> significant time (of the order of hours for a couple of thousand >> elements) and >> 9.2 took twice as long as 7.1. I had to place an assert per memory >> location to >> reassure me it was doing anything at all. There is some n^2 algorithm >> involved; >> you could see it slow down, and doubling the ROM size quadrupled >> execution time. >> I don't know if this has been fixed in 10.1 yet. >> >> But it's a lovely idea when it actually works. >> >> (Incidentally, according to the resulting webcase, the "something I did >> wrong >> while inferring them" was ... inferring them. And the suggested >> instantiation template glossed over the problem of >> initialisation entirely.) >> >> Synplify probably handles BRAM inference much better; just be aware that >> relying >> on it limits portability. >> >> - Brian > > Another limitation I have heard is that you can't infer dual port ram of > differing port widths. > > -Jeff Or with differnt clocks. (OK, they may get inferred, but not efficiently.) JTWArticle: 130859
On Mar 28, 2:34 pm, dalai lamah <antonio12...@hotmail.com> wrote: > Un bel giorno Antti digit=F2: > > > I can not imagine that the server overload is such a real problem that > > Xilinx hasnt been able to solve it during the many years of repeated > > webserver problems. > > Yes, and now they are trying to fix it with some stupid Java applets > (probably they are hosting the file somewhere else but don't want the user= > to see the direct link). > > I don't understand why the big companies don't distribute their software > with BitTorrent. It would be so nice, fast and easy for everyone. It would= > especially make sense for Xilinx, that offers a 2 GB software for free, an= d > poses as the friendly neighborhood multinational. ,-) > > -- > emboliaschizoide.splinder.com I can tell you exactly why they don't use bittorrent, because they want to keep track of who has downloaded their software. They don't want it out there being used by anonymous people that they can't send their sales weasels calling on.Article: 130860
Jeff Cunningham wrote: > > Another limitation I have heard is that you can't infer dual port ram of > differing port widths. > I prefer to infer multiple BRAMs, and simply wire them up to have a different input/output width, at the possible cost of a few extra BRAMs and a small amount of logic. This cost disappears if you are creating a memory that is big enough that you need the extra BRAMs anyway. If I don't want to waste the BRAMs, I prefer to directly instantiate the BRAM, rather than use coregen.Article: 130861
Duane Clark wrote:
> I prefer to infer multiple BRAMs, and simply wire them up to have a
> different input/output width, at the possible cost of a few extra BRAMs
> and a small amount of logic. This cost disappears if you are creating a
> memory that is big enough that you need the extra BRAMs anyway.
... not to mention the extra value inherent in portable code.
-- Mike Treseler
Article: 130862On 3 Apr., 20:30, Andy Peters <goo...@latke.net> wrote: > On Apr 3, 3:10 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > PS, I was thinking that 10.1 is not suggested for ML505, but when i > > just NOW opened the ml505 support PDFs they list ISE 10.1 and EDK 10.1 > > > Xilinx, if you say ML505 is to be used with EDK 10.1 then PLEASE fix > > the revup or make the 10.1 version of EDK ref design available! > > > I dont want spend weeks to troubleshoot why xilinx ML505 ref design > > doesnt work with EDK 10.1 > > FWIW, our Avnet FAE told us that the 10.1 EDK was exactly the same as > the 9.2 EDK. It was given a rev bump so that Xilinx wouldn't get the > usual howls about the EDK shipping months after the ISE tools. > > -a same as 10.1 ? HAHA, tell that FAE to...[insert your favortites] AnttiArticle: 130863
jtw wrote: > > Or with differnt clocks. (OK, they may get inferred, but not efficiently.) I'm not sure what you mean. I infer BRAMs with different read/write clocks all the time. It works fine. And the example I gave showed the use of different clocks.Article: 130864
referringto@googlemail.com wrote: > > Years ago I thought about using a serial design to implement a CPU in > a GAL 16V8 or 20V8. > My idea was to map all registers to memory and to use a 64kbit DRAM as > a 256x8 memory > that is accessed bit wise. Refresh would have been automatically > provided by cycling through the registers. > Unfortunately that design never got anywhere. The main issues where > that all the flipflops were eaten up > by state counters and the design got horribly complex. The ALU design > itself was of course negligible. You would need a few 20V8's to make soemthing useful! You could revisit that in CPLDs - but a 64kb DRAM might be hard to find tho! :) The 32K Serial SRAM could replace it tho ? -jgArticle: 130865
"John McCaskill" <jhmccaskill@gmail.com> wrote in message news:c4d146c4-2719-4817-b11c-750da7e80640@s50g2000hsb.googlegroups.com... >Since you mention that you are loading the bitfile over the PCI bus, I >am assuming that the FPGA is on the PCI card, as opposed to a daugher >card. Is this correct? > >If so, you could use the PCI configuration space to tell the cards >appart. If you also know what board the bitfile is for, then the drive >could check to make sure that the board and bitfile versions match, >and refuse to load the bit file if it does not. I was just about to suggest the same solution. PCI spec requires every type of board to have unique Vendor, and device IDs, as well as there are SubSystem IDs. Now, this is all great unless the OP is implementing the PCI bridge in the same FPGA... Ooops... /MikhailArticle: 130866
water9580@yahoo.com wrote: > On Mar 28, 6:47 am, Rube Bumpkin <Some...@somewhere.world> wrote: >> water9...@yahoo.com wrote: >>> On Mar 27, 6:23 am, Rube Bumpkin <Some...@somewhere.world> wrote: >>>> water9...@yahoo.com wrote: >>>>> On Mar 25, 1:17 pm, John_H <newsgr...@johnhandwork.com> wrote: >>>>>> water9...@yahoo.com wrote: >>>>>>> no reply? >>>>>>> water9...@yahoo.com wrote: >>>>>>>> The Linux lspci -xxx command can show my PCIE device header >>>>>>>> space(0x00~0xFF). However,simultaneity,the Correctable Error and >>>>>>>> Unsupported Request error from PCIE Capabilities device status >>>>>>>> register are set. >>>>>>>> I run the PCI Express Configuration Testing program from PCISIG to >>>>>>>> test configure space.The system is halt after click run all test.Reset >>>>>>>> PC and report NMI error. >>>>>>>> why? >>>>>>>> My configuration: PCIEx1, 16bit customize GTP wrapper same as Endpoint >>>>>>>> x1 IP. >>>>>> Do you see anything unusual from your PCI Express protocol analyzer? >>>>> No,i didn't use any protocol analyzer. Only PCISIG Configuration >>>>> Testing program >>>> If this is your first PCI Express design, you need to think about >>>> getting some tools. PCI-SIG recommends a scope with at least 6GHz of >>>> bandwidth. There are a couple of different companies that have PCIE >>>> analyzer solutions. You need to buy, rent, or borrow one. >>>> I've run compliance testing in the Gold suite at PCI-SIG workshops. It >>>> takes me just a couple of minutes to identify the folks that designed >>>> and built a device without having the right tools. There's a real >>>> surprised look on their face when they see the waveforms. Sometimes we >>>> spend the entire scheduled testing period just debugging their design, >>>> electrically. >>>> If your device is failing the Config Test program, you may need to write >>>> some low-level code to generate some simple cycles. You'll want to start >>>> with a single Cfg Read, Type 0 of Register 0, and look at the results. >>>> Follow that up with more reads and writes, stepping through the >>>> enumeration process. If you don't want to do that, the same companies >>>> that make analyzers make exercisers that can generate the necessary >>>> cycles and show you the result of the completions. >>>> Good luck... >>>> RB >>> but,i use a simple tool of windows ,eg:Pcitree. it can read out my >>> PCIE device header content. >>> why ompliance testing prgrame not? >> Yes, but PCITree can't tell you why the values that you are reading are >> wrong. Is it an electrical problem, or a protocol problem? >> >> RB > > but,the all values read out by Pcitree sw are correct. > > why PCI Express Configuration Testing program is halt? Since there's no way to know what ALL of the requests are, or what the completions look like, there's no way to tell. A protocol analyzer could tell you in less than 10 minutes. RBArticle: 130867
SRLen7 : SRL16
-- synthesis translate_off
generic map( INIT => x"0000")
-- synthesis translate_on
port map (Q => enadd5_d4,
A0 => '1', A1 => '1', A2 => '0', A3 => '0',
CLK => clock, D => enadd5);
PROCESS(clock,reset)
begin
if reset ='1' then
BITVECTOR4 <= (others => '0'); EVECTOR4 <= (others => '0');
elsif clock'event and clock ='1' then
if equal9='1' and enadd5_d4='1' then
BITVECTOR4 <= bitv; EVECTOR4 <= endvector;
else
BITVECTOR4 <= (others => '0'); EVECTOR4 <= (others => '0');
end if;
end if;
end process;
I had the above code synthesized by using synplify pro and it gave me
a negative slack :
Type Pin
Net Time Slack
SRLen7 SRL16 Q
enadd5_d4 2.772 -0.707
So I changed the code by moving the output of SRL16 into the process
and reducing the shift delay by one clock
in srl16 and the slack went away.
SRLen7 : SRL16
-- synthesis translate_off
generic map(
INIT => x"0000")
-- synthesis translate_on
port map (Q => enadd5_d3,
A0 => '0', -- changed from 1 to 0
A1 => '1', A2 => '0', A3 =>
'0', CLK => clock, D => enadd5);
PROCESS(clock,reset)
begin
if reset ='1' then
BITVECTOR4 <= (others => '0'); EVECTOR4 <= (others => '0');
enadd5_d4 <= '0'; ---- **********moved
into the process
elsif clock'event and clock ='1' then
enadd5_d4 <= enadd5_d3; ------ ******
if equal9='1' and enadd5_d4='1' then
BITVECTOR4 <= bitv; EVECTOR4 <= endvector;
else
BITVECTOR4 <= (others => '0'); EVECTOR4 <= (others
=> '0');
end if;
end if;
end process;
I had changed the code because of a suggestion in one of the notes to
get the signal inside into the process in case it doesnt meet the
timing. thats what I did and got the timing corrected.
What I dont understand is SRL16 is a simple shift reister and the
output of SRL16 is just like any other flipflop output with no
combinational logic at the output.
So why was it generating a negative slack since if u see the code the
signal enadd5_d4 is not at all critical but the synplify gives it a
critical status. I am digging into the synplify pro docs too in the
meantime.
Article: 130868The following module generates this error: The logic for <ld> does not match a known FF or Latch template. The logic for <led> does not match a known FF or Latch template. What I want to do is to have a module that can keep the input signal d high in 'ld' for a certain amount of time (16 clocks). During that time period, led would blink with a frequency clk_freq/(2^blink_freq). THere are a couple of problems 1) I need a module register to hold the signal 'd' when it goes high, usually 'd' only maintains high for a single clock period. 2) I need a test when 'd' is no longer active and after a certain amount of time, led should turn off. Now my code has a precision problem, it does not reliably count high time. I need help to straighten out this code. Where can I get some sample verilog to look at (small modules that implement simple things)? Thanks, module blink(input clk, input d, output reg led); parameter blink_freq = 23; paremeter high_time = 4; // 16 clocks reg ld = 0; reg [blink_freq:0] count; reg [high_time:0] hcount; always @(posedge clk or posedge d) begin if(clk) begin count <= count + 1; hcount <= hcount + 1; end if(d) ld = d; else if (hcount[high_time]) ld = 0; if(ld) led <= count[blink_freq]; else led <= 0; end endmoduleArticle: 130869
"Duane Clark" <user@domaininvalid.com> wrote in message news:mscJj.25$iK6.13@nlpi069.nbdc.sbc.com... > jtw wrote: >> >> Or with differnt clocks. (OK, they may get inferred, but not >> efficiently.) > > I'm not sure what you mean. I infer BRAMs with different read/write clocks > all the time. It works fine. And the example I gave showed the use of > different clocks. The specifc issue I had a few years back was using BRAMs with one port write-only, and the other port read with a simultaneous write to clear. Synplify doubled the required amount of BRAMs. JTWArticle: 130870
On Mar 23, 6:40 pm, Jon Elson <el...@pico-systems.com> wrote: > I got a batch of "Xilinx" Spartan XCS30 FPGAs from a Chinese > seller, and am having problems with random failures at first > power up. Sometimes it is a stuck I/O pin, sometimes a failure > to configure. I first thought maybe we had an ESD problem, but > I'm now thinking these may be counterfeit. They have white ink > printed labels on the front, whereas other Xilinx chips have > laser-etched labels. Also, these Spartan chips don't have the > Spartan logo just below the Xilinx logo, like my other Xilinx > chips. Anyone have any comments on this? > > Jon While I have never had to use them for counterfeit detection, I have use Process Sciences for process control, inspection and rework for several years now. I have always been very happy with their work. They have some information about their counterfeit detection services here: http://www.process-sciences.com/services/counterfeit_detection.asp One of the trade journals I get has been running a series of articles about counterfeit parts. I think it was either EE Times, or EDN. Some of the things that they mentioned include remarking to a better speed grade, a lower power version, or a larger memory size. Regards, John McCaskill www.FasterTechnology.comArticle: 130871
On Thu, 03 Apr 2008 21:24:06 -0400, Fei Liu <fei.liu@gmail.com> wrote: >The following module generates this error: >The logic for <ld> does not match a known FF or Latch template. >The logic for <led> does not match a known FF or Latch template. > >What I want to do is to have a module that can keep the input signal d >high in 'ld' for a certain amount of time (16 clocks). During that time >period, led would blink with a frequency clk_freq/(2^blink_freq). > >THere are a couple of problems > >1) I need a module register to hold the signal 'd' when it goes high, >usually 'd' only maintains high for a single clock period. > >2) I need a test when 'd' is no longer active and after a certain amount >of time, led should turn off. Now my code has a precision problem, it >does not reliably count high time. > >I need help to straighten out this code. Where can I get some sample >verilog to look at (small modules that implement simple things)? > >Thanks, > >module blink(input clk, input d, output reg led); >parameter blink_freq = 23; >paremeter high_time = 4; // 16 clocks >reg ld = 0; >reg [blink_freq:0] count; >reg [high_time:0] hcount; > >always @(posedge clk or posedge d) begin > if(clk) begin > count <= count + 1; > hcount <= hcount + 1; > end > if(d) ld = d; > else if (hcount[high_time]) > ld = 0; > if(ld) led <= count[blink_freq]; > else led <= 0; >end > >endmodule simulate this first initial count = 0; initial hcount = 0; initial ld = 0; initial led = 0; always @(posedge clk) begin count <= count + 1; hcount <= hcount + 1; if(d) ld <= d; else if (hcount[high_time]) ld <= 0; if(ld) led <= count[blink_freq]; else led <= 0; end and then you can try to figure out how to get initial values for count etc with a reset signal.Article: 130872
Hi. I have common configuration scheme for Altera Stratix II: flash memory + Max device + Stratix II. Flash memory configured by FPP method thru JTAG. Is there any simple method to download flash memory contents thru Stratix II device and thru JTAG port to computer?Article: 130873
> > Years ago I thought about using a serial design to implement a CPU in > > a GAL 16V8 or 20V8. > > My idea was to map all registers to memory and to use a 64kbit DRAM as > > a 256x8 memory > > that is accessed bit wise. Refresh would have been automatically > > provided by cycling through the registers. > > Unfortunately that design never got anywhere. The main issues where > > that all the flipflops were eaten up > > by state counters and the design got horribly complex. The ALU design > > itself was of course negligible. > > You would need a few 20V8's to make soemthing useful! Obviously the point was specifically to do something useful with a single 20V8 :) It was the next challenge after maxing out on CPLDs (see http://www.opencores.org/projects.cgi/web/mcpu/overview). > You could revisit that in CPLDs - but a 64kb DRAM might be hard to > find tho! :) 4164s are still easy to come by as NOS - actually I have several tubes of them. Of course this is nothing for a new design, but GALs are of similar vintage so nothing seems wrong with marrying them to an antique DRAM. Actually a better challenge may be to design a CPU with a minimum number standard logic chips. Even though it is highly anachronistic in the age of programmable logic, a hard wired sea-of-gates still has something gratifying to it.Article: 130874
In my .mcs file it says in the beginning rows:
:020000040000FA
:10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
:10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0
:10002000AA9930A100072000316109EE33213C0F6D
^^^^^^here
But the xspi complains about a missing synchronization word. Isn't the AA99
the synchronization word for a Spartan-3A (on the last pasted row)?
Is it only that xspi is incompatible with recognizing this?
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