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
Hi Mark,
Thanks for your comment.
Is the waiting for TIP and ack an "and" function i.e. both must be
deasserted before proceeding to the next step? Is the ack you are
referring to is the ack from Status Register bit 7 or from wb_ack_o?
Thanks,
-M
Mark McDougall wrote:
> markus wrote:
>
> > I am wondering if any of you have encountered a problem in which the
> > Opencores' I2C "READ" function failed.
>
> I've successfully used the core on 2 different designs...
>
> > In order to initiate a read sequence, I first sent a write to the
> > slave, followed by the memory address location of the slave's register,
> > then I sent the read instruction. I checked whether wb_ack_o pin is
> > asserted and that the TIP signal have been negated before proceeding
> > from one command to another. Is there something else that I need to do
> > prior to executing from one command to another (i.e. more pauses?)? Or
> > do I need to turn on clock stretching? I thought the clock stretching
> > is supported automatically.
>
> Here's the sequence I use to read a byte...
>
> // device address and dummy write
> WR(TXR,{dev,0})
> WR(CR,STA|WR)
> wait for not tip and ack
> // memory address
> WR(TXR,addr)
> WR(CR,WR)
> wait for not tip and ack
> // start reading
> WR(TXR,{dev,1})
> WR(CR,STA|WR)
> wait for not tip and ack
> WR(CR,RD|ACK|STO)
> wait for not tip
> RD(RXR)
>
> 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
Article: 112126John McGrath wrote: > I assume, because we are talking about glitches, that changes in Sig > are effectively asynch to the clk - so shouldn't it be synchronised > with a 2 flip-flop synchronizer first, or else the counter could count > incorrectly? (some flip-flops seeing the value as a 1, others seeing it > as a 0 ) perhaps the nature of the system means it can recover from > that, but I think it would make it safer. > (I've had a few glasses of wine too, so the same disclaimer for me!) > Cheers > John > > PeteS wrote: >> A small fix :) >> >> PeteS wrote: >>> Frank Buss wrote: >>>> I have built a prototyp board with wires between the FPGA and an external >>>> component. With the scope I can see glitches (looks like from crosstalk >>>> when switching other signals) and multiple transitions are detected by >>>> the >>>> FPGA when switching signals. Looks like the noise is < 200 ns. The period >>>> of the wanted signal is > 3 us. I think with a PCB there would be less >>>> problems, but there is lots of space left inside the FPGA, so it >>>> should be >>>> possible enhance the signal with logic so that it works even with the >>>> noisy >>>> wired prototype. What do you do normally to solve this kind of problems? >>>> >>>> My idea is to use a low-pass filter: a n bit counter, which is >>>> incremented >>>> with system clock, if the input signal is 1 and decremented otherwise. If >>>> all n bits are 1, the counter is not incremented and if all bits are >>>> 0, it >>>> is not decremented. If the highest bit is set, then the sampled signal is >>>> considered as 1, otherwise as 0. I could encapsulate this function >>>> within a >>>> VHDL entity, so it is easy to use it for multiple input signals and >>>> maybe a >>>> generic for specifying n. >>>> >>> Hi Frank >>> >>> You are describing a soft filter. >>> >>> I have a number of them in a current design (it's in a rather noisy >>> environment) and I use a 5 bit counter as part of a state machine. >>> >>> I assume you have an appropriate clock, so simply qualify the signal as >>> continuously present (or perhaps mostly present) for the 3us you state. >>> >>> With a 10MHz clock, for example, a 5 bit counter is almost perfect (and >>> besides, we can always terminate at count = 30 ;) >>> >>> I like your approach, but this is simple and uses pretty limited resources. >>> >>> so, somewhere >>> >>> wire Sig; // the signal we are watching >>> reg SigValid; // valid indicator >>> reg [4:0] SigCount; >>> >>> >>> always @(posedge clk) >>> begin >>> if (!Sig) >>> begin >>> SigCount <= 5'b00000; // signal disappeared, clear counter >>> SigValid <= 1'b0; >>> end >>> else if(Sig & SigCount < 28) >>> begin >>> SigCount <= SigCount+1; >>> >>> end >> // fix the next line >> // was else if (SigCount == 28) >> else if (Sig & SigCount == 28) >> >> // qualify signal properly >> >>> begin >>> SigValid <= 1'b1; // Signal has been true for 30 >>> consecutive // clocks. >>> end >>> end >>> >>> Simple, as I said, and if you find bugs, I state in my defence I have >>> had a couple of glasses of wine :) >>> >>> >>> Cheers >>> >>> PeteS > Well, in this case, I have a 5 flipflop synchroniser :) Cheers PeteSArticle: 112127
Frank Buss wrote: > entity low_pass_filter is > generic( > counter_max: positive := 30; > hysteresis: positive := 5); Some corrections: hysteresis doesn't make sense. I've deleted it and tested in low-state for counter=counter_max and in high-state for counter=0 and tested it today with real hardware and it works. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 112128
Frank Buss wrote: > Frank Buss wrote: > >> entity low_pass_filter is >> generic( >> counter_max: positive := 30; >> hysteresis: positive := 5); > > Some corrections: hysteresis doesn't make sense. I've deleted it and tested > in low-state for counter=counter_max and in high-state for counter=0 and > tested it today with real hardware and it works. > Well, good! If talking through a problem helps you solve it, only too glad to talk :) Cheers PeteSArticle: 112129
Austin Lesea wrote: > John, > > Right you are. Spartan 2 is like "classic Coca-Cola", it is really hard > to improve upon. > > Even the original Spartan (4KXLA derivative) is still going strong. Another advantage is that they are available in PLCC, I've got a tube of them somewhere. LeonArticle: 112130
PeteS wrote: > > I seem to recall from the distant past that the 8080 (some versions) > used depletion load; i.e. a depletion mode device with gate tied to > source instead of a resistive load. Not that it reduces the components > (an in fact adds a pin per active transistor). > So do these depletion loads count in the 8000 transistors? Then, the 8080 function could maybe be performed by 4000 active devices and 4000 resistors. (Im sort of thinking that it was 8000 amplifying transistors in the count, 4000 just seems too low, as you'd need 2 for every FF, and the 8080 actually had a lot of registers, for the time.) JonArticle: 112131
logjam wrote: >>we have 6000 times 5 components (2 diodes, 2 res, one trans) = 30,000 >>components. >>Does this still sound practical? >> >> > >Not practical, but fun! I have a 88x40 inch display made out of 19,008 >T 1 3/4 LEDs for example... ;) > > > >>Anyway, it should be fairly easy to design the CPU for FPGA implementation. >>I'd forget the TTL component emulation, and use either VHDL or Verilog, >>or maybe >>one of the RTL synthesis tools. These are able to specify a CPU very >>concisely. >> >> > >Would there be a simple way of generating some sort of human >understandable information that would help generate a schematic? > > Yes, RTL was used as a descriptive tool for YEARS before there ever was a synthesis tool that accepted it. JonArticle: 112132
Hi On what factors the maximum operating frequency of ahb master and slave depends ? in general what is the maximum frequency we can go for ? regardsArticle: 112133
edit arch/ppc/platforms/xilinx_ocp/xilinx_syms.c and change references to XpacketFifoV100a -> XpacketFifoV200a (there's an include file and 4 EXPORT_SYMBOLs) Peter Mendham wrote: > Dear all, > > I'm trying to build a straightforward Linux Kernel for the Xilinx ML405 > board and I'm running into one small problem. The build gets most of > the way through and fails at link stage, missing a crucial function. > The function in question is part of the Xilinx OCP BSP in the file > xpacket_fifo_v2_00_a.c Tracing make, as best I can, this file never > gets built. The only code that uses the function is in a driver and > hence only "meets up" with the functions at final link time, which is > where the problem arises. > > Now, I'm certainly not a make guru, so I don't really understand how > make calculates the dependencies during make dep (all these .depend > files) and I'm not sure how make then uses these to build the required > output files. How do I coax make into building the missing file(s)? > Does anyone have any experience building kernels for the ML405? > > I'm building a PPC development 2.4 downloaded using bitkeeper. I'm > (mostly) following the instructions here: > http://splish.ee.byu.edu/projects/LinuxFPGA/configuring.htm which are > for the ML403, but close enough. > > Any help - however small - would be great. > > TIA, > > -- PeterArticle: 112134
I am new to CPLD's and I am trying to make a new design incorporating some of the old abel code. I am using schematic entry (XC9572). I have converted the abel code into symbols and incorporating them to my schematic. In the new design I am not using many of the input and outputs that were defined in the abel code but I dont want to fiddle with that and so I am using the code as it is. Now when I synthesize I get following warnings.. WARNING:Xst:647 - Input <A00> is never used. WARNING:Xst:646 - Signal <CARRY_12> is assigned but never used. WARNING:Xst:2170 - Unit PN67c : the following signal(s) form a combinatorial loop: _xor0004, BEL, _xor0002 WARNING:Xst:1354 - Port SPAREI is not connected, attached property removed (LOC) Should I worry about these warnings because I am not using all these ports/signals/input? At present I have connected all unused inputs to ground and left the unused outputs as it is. Is that the right approach? Thanks for any responses...Article: 112135
It seems to be annoying to have my data valid on the rising edge of a
clock internal to the FPGA. If I have a process that has logic on the
rising edge of a clock that generates or processes some sort of data,
and another process that samples this data, to say put into a memory
buffer. What are you guys doing in order to skew the clock out of
phase so it samples the data on the rising edge of this clock? For
example if you have
process(clk)
begin
if(clk'event and clk='1') then
some_array(some_index) <= data;
end if;
end process;
and ....
process(clk)
begin
if(clk'event and clk='1') then
data <= data+1;
end if;
end process;
This will have a horrible outcome because the data is not valid on the
rising edge? Right? What is a nice way to get around this? Besides
using things like clock managers?
Article: 112136nfirtaps wrote: > It seems to be annoying to have my data valid on the rising edge of a > clock internal to the FPGA. It's valid for the entire clock cycle AFTER the leading edge... > If I have a process that has logic on the > rising edge of a clock that generates or processes some sort of data, > and another process that samples this data, to say put into a memory > buffer. What are you guys doing in order to skew the clock out of > phase so it samples the data on the rising edge of this clock? Using standard logic design techniques that have been in existence for decades. You're not grasping the fact that any flip flop changes state only AFTER the rising edge of the clock....which is exactly what your processes say as well. > For > example if you have > > process(clk) > begin > if(clk'event and clk='1') then -- KJ: You won't get here until AFTER the rising edge of the clock. > some_array(some_index) <= data; > end if; > end process; > > and .... > > process(clk) > begin > if(clk'event and clk='1') then -- KJ: You won't get here until AFTER the rising edge of the clock. > data <= data+1; > end if; > end process; > > This will have a horrible outcome because the data is not valid on the > rising edge? Sure it's valid, it won't start to change until AFTER the rising edge but it get sampled on what is there right AT the rising edge...not after, not before. The only 'difference' between simulation and real world flip flops is that a real world device will have a propogation delay specified in nanoseconds whereas the simulation environment the delay will be one simulation delta cycle. > Right? Wrong. > What is a nice way to get around this? Besides > using things like clock managers? Design using standard synchronous design techniques. In fact the two processes you've shown will do exactly what you want them to do; there will be a two clock cycle latency between when 'data' first switches and when the memory gets updated, but that's exactly what you specified that you wanted which is also the way that most people would go about doing what you appear to want. You wouldn't use any sort of 'clock manager' or anything else to skew the clock either. KJArticle: 112137
nfirtaps wrote:
> It seems to be annoying to have my data valid on the rising edge of a
> clock internal to the FPGA.
Synchronous data is valid for a long time before
the rising clock edge, but only for a short time
after the edge. I am always sampling the
"old" value, so what happens during the clock
to Q change does not really matter.
-- Mike Treseler
Article: 112138learnfpga wrote: > I am new to CPLD's and I am trying to make a new design incorporating > some of the old abel code. I am using schematic entry (XC9572). I have > converted the abel code into symbols and incorporating them to my > schematic. In the new design I am not using many of the input and > outputs that were defined in the abel code but I dont want to fiddle > with that and so I am using the code as it is. > > Now when I synthesize I get following warnings.. > > WARNING:Xst:647 - Input <A00> is never used. > > WARNING:Xst:646 - Signal <CARRY_12> is assigned but never used. > > WARNING:Xst:2170 - Unit PN67c : the following signal(s) form a > combinatorial loop: _xor0004, BEL, _xor0002 > > WARNING:Xst:1354 - Port SPAREI is not connected, attached property > removed (LOC) > > > Should I worry about these warnings because I am not using all these > ports/signals/input? > > At present I have connected all unused inputs to ground and left the > unused outputs as it is. Is that the right approach? > > Thanks for any responses... Check the fitter report files, they will show you what _actually_ happened. Why design in schematic, if you already have the code in abel ?. AFAIK Xilinx still supports that flow fine for CPLDs. -jgArticle: 112139
Antti wrote: > Gabor schrieb: > > > I'm seeing some strange behavior when trying to program > > a Spartan 2e (XC2S150E) directly via JTAG. In the system > > it is normally programmed using master serial mode from > > the XCF02S "platform flash" part. The JTAG chain starts > > with the XCF02S and then ends at the XC2S150E - no > > other parts. I can program the XCF02S without problem > > using JTAG. I can also program the XC2S150E without > > problems via JTAG _IF_ the XCF02S is blank. Once the > > FPGA has been programmed from the XCF02S using > > master serial mode, which is the normal case after > > power-up, attempts to re-program the FPGA using JTAG > > fail. This does not seem to be a problem with the > > FPGA running. I can re-program the FPGA via JTAG > > when it is running _IF_ the FPGA was originally configured > > via JTAG. I have opened a web case on this, but I thought > > someone here may have some insight on this issue. I > > saw in an old thread the following note: > > > > David Kinsell wrote: > > > > We've seen different problems with an XCF02S in the chain ahead of a > > Spartan 2 part. Done never goes high on the Spartan when attempting > > JTAG programming. Take the XCF02 out of the chain and it works. > > Discovered that if the XCF02 is blank, then we can program the Spartan > > OK. Xilinx has some answer records (18644 and others) on related > > issues, but that didn't seem to apply to us. > > this issue can cause problems for different parts, no matter if there > is an Xilinx AR or not > > the thing is that if any non-JTAG config interface shifts in valid SYNC > word > during some specifig time in the JTAG config process then the JTAG > configuration will fail. > > happens with XCFxx master serial mode, happens with Se3 BPI mode (at > least early silicon) > etc, etc.. > > so just make sure the config is blank > > antti Thanks, Antti. I was hoping this wasn't the answer. The current hardware revision in the field requires the FPGA to boot from the XCF02S in order to provide a clean reset signal to an embedded processor. There is no way for the processor to boot up and program the FPGA in these boards if the FPGA isn't already running some version. In order to change this behavior I need wiring changes to the boards, and using wires I have a lot of possible ways to work around the issue. It would have been nice to fix this in "software" only. Right now my only "software" solution is to re-program the XCF02S if I want to upgrade the FPGA bitstream. If this process gets interrupted I would end up with a non-working system. :-( Regards, GaborArticle: 112140
Except the asynch control signal is going to all 5 flip-flops at the same time, which means if it came at just the wrong time, some would capture it, and others would not - causing unexpected behaviour. in a real synchronizer, the asynch signal only goes to one flip-flop. PeteS wrote: > John McGrath wrote: > > I assume, because we are talking about glitches, that changes in Sig > > are effectively asynch to the clk - so shouldn't it be synchronised > > with a 2 flip-flop synchronizer first, or else the counter could count > > incorrectly? (some flip-flops seeing the value as a 1, others seeing it > > as a 0 ) perhaps the nature of the system means it can recover from > > that, but I think it would make it safer. > > (I've had a few glasses of wine too, so the same disclaimer for me!) > > Cheers > > John > > > > PeteS wrote: > >> A small fix :) > >> > >> PeteS wrote: > >>> Frank Buss wrote: > >>>> I have built a prototyp board with wires between the FPGA and an external > >>>> component. With the scope I can see glitches (looks like from crosstalk > >>>> when switching other signals) and multiple transitions are detected by > >>>> the > >>>> FPGA when switching signals. Looks like the noise is < 200 ns. The period > >>>> of the wanted signal is > 3 us. I think with a PCB there would be less > >>>> problems, but there is lots of space left inside the FPGA, so it > >>>> should be > >>>> possible enhance the signal with logic so that it works even with the > >>>> noisy > >>>> wired prototype. What do you do normally to solve this kind of problems? > >>>> > >>>> My idea is to use a low-pass filter: a n bit counter, which is > >>>> incremented > >>>> with system clock, if the input signal is 1 and decremented otherwise. If > >>>> all n bits are 1, the counter is not incremented and if all bits are > >>>> 0, it > >>>> is not decremented. If the highest bit is set, then the sampled signal is > >>>> considered as 1, otherwise as 0. I could encapsulate this function > >>>> within a > >>>> VHDL entity, so it is easy to use it for multiple input signals and > >>>> maybe a > >>>> generic for specifying n. > >>>> > >>> Hi Frank > >>> > >>> You are describing a soft filter. > >>> > >>> I have a number of them in a current design (it's in a rather noisy > >>> environment) and I use a 5 bit counter as part of a state machine. > >>> > >>> I assume you have an appropriate clock, so simply qualify the signal as > >>> continuously present (or perhaps mostly present) for the 3us you state. > >>> > >>> With a 10MHz clock, for example, a 5 bit counter is almost perfect (and > >>> besides, we can always terminate at count = 30 ;) > >>> > >>> I like your approach, but this is simple and uses pretty limited resources. > >>> > >>> so, somewhere > >>> > >>> wire Sig; // the signal we are watching > >>> reg SigValid; // valid indicator > >>> reg [4:0] SigCount; > >>> > >>> > >>> always @(posedge clk) > >>> begin > >>> if (!Sig) > >>> begin > >>> SigCount <= 5'b00000; // signal disappeared, clear counter > >>> SigValid <= 1'b0; > >>> end > >>> else if(Sig & SigCount < 28) > >>> begin > >>> SigCount <= SigCount+1; > >>> > >>> end > >> // fix the next line > >> // was else if (SigCount == 28) > >> else if (Sig & SigCount == 28) > >> > >> // qualify signal properly > >> > >>> begin > >>> SigValid <= 1'b1; // Signal has been true for 30 > >>> consecutive // clocks. > >>> end > >>> end > >>> > >>> Simple, as I said, and if you find bugs, I state in my defence I have > >>> had a couple of glasses of wine :) > >>> > >>> > >>> Cheers > >>> > >>> PeteS > > > > Well, in this case, I have a 5 flipflop synchroniser :) > > Cheers > > PeteSArticle: 112141
What would you guys recomend as a bus transciever for interfacing with standard TTL and low power TTL logic? I'm thinking that the TI 74AC11245 would work. The high/low thresholds seem to be good and it will tollerate 5v input on the bus side... Thanks, GrantArticle: 112142
Grant Stockly wrote: > What would you guys recomend as a bus transciever for interfacing with > standard TTL and low power TTL logic? I'm thinking that the TI > 74AC11245 would work. The high/low thresholds seem to be good and it > will tollerate 5v input on the bus side... > > Thanks, > Grant The AC part isn't TTL. True TTL has Vih=2.0V and Vil=0.8V levels which are entirely compatible with the 3.3V Vcco powered LVTTL IOSTANDARD. If you're using a hybrid technology like ACT logic where the inputs are TTL compatible but the outputs are CMOS swing, simple series resistors will allow your 3.3V Vcco powered LVTTL inputs to deal with the high rails. It might be "safer" to include those resistors with classic 5V powered TTL devices anyway. The series resistor is a consideration if you're doing I/Os over long lines for high slew rate edges because the resistor value is much larger than the characteristic impedance of the circuit board trace. Those are the only signals you have to pay closer attention to. The appropriate resistor values and the data to back up the value selection are found in various pieces of the FPGA documentation.Article: 112143
Hi all, Im very new to XILINX development bubt for a class project we were assigned the task of building a MP3 player. We were given a decoder and a mem-reader so we pretty much need to feed data to it and get the output. But Im not entirely sure how to read data from the onboard memory. Has anyone done sonething like this before? Any help would be appreciated thanks - jonArticle: 112144
Jim Granville" <no.spam@designtools.maps.co.nz> schrieb im Newsbeitrag news:455cf081$1@clear.net.nz... > learnfpga wrote: >> I am new to CPLD's and I am trying to make a new design incorporating >> some of the old abel code. I am using schematic entry (XC9572). I have >> converted the abel code into symbols and incorporating them to my >> schematic. In the new design I am not using many of the input and >> outputs that were defined in the abel code but I dont want to fiddle >> with that and so I am using the code as it is. >> >> Now when I synthesize I get following warnings.. >> >> WARNING:Xst:647 - Input <A00> is never used. >> >> WARNING:Xst:646 - Signal <CARRY_12> is assigned but never used. >> >> WARNING:Xst:2170 - Unit PN67c : the following signal(s) form a >> combinatorial loop: _xor0004, BEL, _xor0002 >> >> WARNING:Xst:1354 - Port SPAREI is not connected, attached property >> removed (LOC) >> >> >> Should I worry about these warnings because I am not using all these >> ports/signals/input? >> >> At present I have connected all unused inputs to ground and left the >> unused outputs as it is. Is that the right approach? >> >> Thanks for any responses... > > Check the fitter report files, they will show you what _actually_ > happened. > > Why design in schematic, if you already have the code in abel ?. > AFAIK Xilinx still supports that flow fine for CPLDs. > > -jg > Jim this is a bug in ISE 8.x it only happens for 95xx CPLDs IMHO the only solution is to use ISE 7.1 or 6.3 for XC95xx AnttiArticle: 112145
I have some combinational loops in my design.2 blocks are there with interface .1 st block output is going to second one input. and vice versa.problem is the pins of the blocks are dissappearing in the postfitting of design.How to constrain.I am using quartus s/w 6.0 version with cyclone II deviceArticle: 112146
On 2006-11-16, olson_ord@yahoo.it <olson_ord@yahoo.it> wrote: > I hope you can tell me what is the size of the circuits that you guys > synthesize? Am I trying something impossible here? - I thought 10K was > a small size. I would be glad to hear of any ideas you may have on how > to get this to synthesize. I am not so much concerned about the run > time - but that it works without crashing. If it turns up that your source code is too complicated to synthesize with your current machine you could perhaps divide your design into several files and compile each file separately. One keyword to search for is incremental synthesis. /AndreasArticle: 112147
What are you doing with TMS during this. Your post suggests you throw a pattern at TDI and then expect data out of TDO. Colin Antti Lukats wrote: > <florent.peyrard@gmail.com> schrieb im Newsbeitrag > news:1163696998.857615.68930@h54g2000cwb.googlegroups.com... > > Hi all, > > > > i'm new to boundary scan and want to make it work in the xilinx starter > > board, which contains a spartan-3 FPGA (xc3s200) and a platform flash > > PROM (xcF02s). > > > > i'd like to make just a simple test, independantly of any design, just > > to become familiar with this protocol: monitor the value of one of the > > 8 switches of the board. here is what i did: i entered an instruction: > > 000001 11111111 to put the PROM in bypass mode and the fpga in SAMPLE > > mode. then i shift data out but the expected value doen't appear on TDO > > after the expected number of clock edges, it seems that the capture > > state doesn't work. i've read that during configuration, I/Os are not > > connected, maybe this is my problem: i intentionnally changed the > > jumpers to prevent configuration otherwise once configured, boundary > > scan features aren't available any more. but maybe the system stays in > > configuration mode, waiting for configuration and disabling I/Os until > > configuration is done...can you help about this fact? > > > > and if i give up and try to instantiate the BSCAN_SPARTAN3 component in > > a design in order to make the boundary scan feature available after > > configuration, i just don't undertand at all how to instantiate it: > > what should i link the pins of the symbol to? > > > > thanks a lot in advance, i'm very interested in this technology and it > > would be a shame to give up.. > > > > florent > > > > you are doing something wrong, boundary scan *IS* available before > configuration and it works. > > AnttiArticle: 112148
Gabor schrieb: > Antti wrote: > > Gabor schrieb: > > > > > I'm seeing some strange behavior when trying to program > > > a Spartan 2e (XC2S150E) directly via JTAG. In the system > > > it is normally programmed using master serial mode from > > > the XCF02S "platform flash" part. The JTAG chain starts > > > with the XCF02S and then ends at the XC2S150E - no > > > other parts. I can program the XCF02S without problem > > > using JTAG. I can also program the XC2S150E without > > > problems via JTAG _IF_ the XCF02S is blank. Once the > > > FPGA has been programmed from the XCF02S using > > > master serial mode, which is the normal case after > > > power-up, attempts to re-program the FPGA using JTAG > > > fail. This does not seem to be a problem with the > > > FPGA running. I can re-program the FPGA via JTAG > > > when it is running _IF_ the FPGA was originally configured > > > via JTAG. I have opened a web case on this, but I thought > > > someone here may have some insight on this issue. I > > > saw in an old thread the following note: > > > > > > David Kinsell wrote: > > > > > > We've seen different problems with an XCF02S in the chain ahead of a > > > Spartan 2 part. Done never goes high on the Spartan when attempting > > > JTAG programming. Take the XCF02 out of the chain and it works. > > > Discovered that if the XCF02 is blank, then we can program the Spartan > > > OK. Xilinx has some answer records (18644 and others) on related > > > issues, but that didn't seem to apply to us. > > > > this issue can cause problems for different parts, no matter if there > > is an Xilinx AR or not > > > > the thing is that if any non-JTAG config interface shifts in valid SYNC > > word > > during some specifig time in the JTAG config process then the JTAG > > configuration will fail. > > > > happens with XCFxx master serial mode, happens with Se3 BPI mode (at > > least early silicon) > > etc, etc.. > > > > so just make sure the config is blank > > > > antti > > Thanks, Antti. > > I was hoping this wasn't the answer. The current hardware revision in > the > field requires the FPGA to boot from the XCF02S in order to provide a > clean reset signal to an embedded processor. There is no way for the > processor to boot up and program the FPGA in these boards if the FPGA > isn't already running some version. In order to change this behavior > I need wiring changes to the boards, and using wires I have a lot > of possible ways to work around the issue. It would have been nice > to fix this in "software" only. Right now my only "software" solution > is to re-program the XCF02S if I want to upgrade the FPGA bitstream. > If this process gets interrupted I would end up with a non-working > system. :-( > > Regards, > Gabor well there could be a software only solution, but you need to investigate it I told what the cause, so you need to see if you can bypass the issue make a small CPLD that makes an LED "ON" when it sees FPGA config start pattern being shifted in, attach it to CCLK and DIN then make your own JTAG config software and single step it to program the FPGA and monitor the LED, you might be able to find a sequence of JTAG commands that work and succeed to configure the FPGA no matter if the XCF shifts out the config SYNC at wrong place. if you can gurantee deterministic timing of the JTAG config stream then all you need may be just padding the XCF with dummy to align the SYNC to a time slot where it does not harm the configuration. or at very bottom end you may place XCF in EXTEST mode during the config or at some short time during config to prevent it to trasht the config. so it may be doable but may take several weeks to work it out AnttiArticle: 112149
olson_ord@yahoo.it schrieb:
> circuits and synthesize them to the FPGAs. I read the circuits using
> the ISCAS benchmark format - made my changes to the circuit structure
> and dumped out the VHDL.
[..]
> for a 10K gate circuit - I had a little more than 10K entities. Note
> that I did not increase the number of gates - but I just added
> additional Muxs (multiplexers) and some control lines. I was surprised
> that this modified circuit would not synthesize.
The number of gates _will_ increase, if you add gates!
I guess you even didn't care about signal buffering. A signal driving
10k gates needs roughly 1000 gates for signal buffering.
> A code sample showing one of my gates (with the associated Mux) is
>
> Nand_2_0_0 : forg_node_16_Cell_0 <= not (input_2_Cell_0 and
> node_11_Cell_0);
>
>
> SEL_node_16_Cell_0(1) <= ctrl_fault_4_Cell_0;
> SEL_node_16_Cell_0(2) <= ctrl_fault_5_Cell_0;
node_16_cell_0 <= fault_4_node_16 when (insert_faults_cell_0 =
'1' and SEL_node_16_cell_0 = "01") else
fault_5_node_16 when
(insert_faults_cell_0 = '1' and SEL_node_16_cell_0 = "10") else
forg_node_16_cell_0;
could be a bit smaller code replacement for your mux (won't change
anything concerning synthesis) but you drastically reduce the number of
lines for same functionality.
> (Just imagine that I do this 10K times - including final signal
> mapping.)
This adds roughly 10k times 1 complex gate with 6 inputs and 1 output
to your design without any signal buffering, meaning you double your
gatecount at least. In fact I expect you to need about three times the
design size.
This code seems to introduce combinatorial paths with length of more
than 10k gates.
Don't do this. I guess even 100 gates per path will kill your tool.
BTW: you do this for fault testing, right? Doubling your design to
achieve a fault coverage seems the wrong way for me
bye Thomas
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