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
Sky465nm@trline5.org wrote:
>>> * Check power for any dips or transients.
>
>
>>My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't
>>really know what's causing this (it's just below the minimum required,
>>isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V.
>
>
> XC3S400-PQ208
> http://direct.xilinx.com/bvdocs/publications/ds099.pdf (t31 p58/208)
> Min Nom Max
> Vccint 1.140 1.200 1.260
> Vccaux 2.375 2.500 2.625
> Vcco 1.140 - 3.450
>
> LM1086-2.5
> http://users.ece.utexas.edu/~valvano/Datasheets/LM1086.pdf
> Min Typ Max
> Vout 2.450 2.50 2.525 (Vin=4-18V Ifull)
>
> Current limit: Min=1.5A Typ=2.7A at Vin=8V
>
> Your Vcco regulator uses "3V3" for Vin with a 10uF capacitor on each input
> and output.
> "3V3" comes from S53, S39, S33, S27, S21, C25, C31, C36, C41, C43, C54 on
> the PCI connector (CON1).
> (Schematic: http://wacco.mveas.com/img/schema1d.png)
>
> So the Vin of the 2.5V regulator is not enough.
>
Yep, I realised that too and got just back from uni where I've got
better tools than here at home. The Vin is now tied to 5V and the output
is a clean 2.50V. (Also, I fixed the second led on the CPLD but that's
irrelevant for this discussion)
Still can't program the fpga though.
> Also there's the issue of voltage ramp time upon startup.
> Vcco 2000 us
> Vccaux - us (no requirement)
> Vccint 500 us
> (p57 Table 29 Power voltage ramp time requirements)
>
> So you might need to check Vccint vs Vccaux. The Vccaux should be powered
> before Vccint, but it's not that sensitive (or?). (see p53)
>
Hmm, I checked the fpga and it's a revision E with the GQ fabrication
process code so I guess I'm lucky and don't have to worry about any of this.
> Check that your oscillator does have proper power. And outputs a correct
> waveform at the XC3S400 input (Bank5 GCLK2, P76).
> (LVTTL 0.8 - 2.0 swing + flanks)
>
This is where it gets annoying, I don't have anything to check out the
waveform with. I'll have to drag everything to uni tomorrow if I want to
see what's happening on such lines which is a much bigger effort than
just taking the PCI card - I'll do it anyway, but still. It would be
easier if I was able to program the fpga so I could fling a little
counter-thing on it outputting it to the led.
>
>>> * Connect directly with a parallell port jtag adapter.
>>> Like this: http://www.xilinx.com/support/programr/jtag_cable.pdf
>>> (And only try the USB approch once it confirmed to work)
>
>
>>The thing is, the programmer is embedded on the board itself so
>>connecting a different programmer would require me to start cutting pcb
>>traces.
>
>
> Measure the output of your onboard usb programmer that it does what you
> expect it to do. Ie feedback it's TDO to your parallell port.
> If this fails, try the cut traces approach and solder some wires so you can
> change programmer at will.
>
> Also use program directly via JTAG mode to start with, only when that works
> try eeprom. The first bitstream ("program") should be something simple like
> pulsing a LED.
>
Right now the program is exactly (except for pinout of course) the same
as the thing I flashed succesfully into the CPLD. It had the led tied to
counter[25] where counter = counter + 1 on every posedge clk. I'm
completely ignoring the eeprom at the moment.
> (604-00033G-ND IC FTDI2232L USB/SERIAL 48-LQFP)
>
> Scan chain (reverse order?):
> FTDI2232L - XC95144XL - XC3S400 - XCF01S - FTDI2232L
>
>
It's FTDI tdi -> XCF04S -> XC3S400 -> XC95144XL -> FTDI tdo
>>> * Lower the clocking frequency, try 50 kHz.
>
>
>>Didn't seem to help. Afaik there's no minimum clock so I even tried it
>>at ~100Hz (which takes forever btw, in case you never tried it) but it
>>still failed.
>
>
> Verify bitstream at TDI+TCK?
>
The CPLD verifies so I'm pretty sure it's not the programmer. I'll do a
debug output though and check it by hand tonight.
> {M0,M1,M2} = 3'b000 (ds099 p45 for mode table)
>
> So configuration mode is master serial. Thus CCLK+DIN is the ones that
> dictates programming. Setting M0=1, M1=0, M2=1 gives you jtag programming
> mode. Which might make life easier in the beginning. It's also the mode
> that is smoother to use when developing.
>
All documentation seems to say that M[2:0] don't matter at all when you
want to program using JTAG, say, the first line of the chapter "JTAG
Configuration Mode" of ug332 (page 187).
http://www.xilinx.com/support/documentation/user_guides/ug332.pdf
>
>>> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B,
>>> CCLK, etc)
>
>
>>M[2:0] are all tied to ground, and changing this would again require
>>some force so I'd rather not. This shouldn't matter afaik, since you can
>>always program using JTAG anyway, right? Likewise, when configuring
>>using JTAG it doesn't matter what CCLK is, does it? I mentioned the
>>state of INIT_B, PROG_B and DONE earlier.
>
>
> M[2:0] = 000 => Master serial mode according to datasheet ds099 page 45.
> So CCLK will matter. Btw, check if CCLK (2.5V) does output a proper waveform
> at the eeprom input (Pin3 CLK). And that eeprom output is correct at the fpga.
>
> Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V
>
Sorry you lost me - is this a problem? I followed figure 4 of xapp453 to
enable 3.3V powered programming;
http://www.xilinx.com/support/documentation/application_notes/xapp453.pdf
Rpar is R24 in case you can't find it in my (unfortunately somewhat
confusing) schematic.
The only changes I made is the DONE pin connection because I want to
imitate the behavior of Figure 1 of xapp694, which makes it possible to
use parts of the eeprom for user data.
http://www.xilinx.com/support/documentation/application_notes/xapp694.pdf
> Signals:
> INIT_B Shall go high after memory is cleared. And shall not be tied low.
Is low, goes high when programming starts, goes back to low after that
> PROG_B Goes high?
Always high
> DONE Goes high after configuration is complete.
Always low
> HSWAP_EN Is tied low in your schematic => Pullup resistors enabled on all
> pins not activly involved in the configuration process.
> Check that no pullup'ed pin interfere with the configuration process.
> (ds099 p101)
>
I wouldn't know which one besides the ones already mentioned. The only
user IO pin that's connected to any of these is P102 (bank 4) which is
tied to CCLK so I can clock out user data at a later point after
configuration. A pull-up on CCLK shouldn't matter afaik.
> You might use these to find out what's going on.
>
>
>>> * You could connect pins to the fpga DIN etc.. back to your PC to verify your
>>> fpga actually get the data you expect.
>
>
>>Would data pushed in through JTAG appear on DIN? I could write something
>>that checks TDO but I'm told the spartan spits out zeroes or other
>>nonsense when I'm shifting data in.
>
>
> My idea was to attach a wire directly to TDI/TDO + TCK back into an INPUT pin
> of the parallell port to verify data.
>
>
Hmm. Not sure if that's possible, I'd need at least a tool to sample the
parallel port correctly. I'll check the data I'm sending to the FTDI
first, maybe something odd is happening in there.
>>Thorsten Trenz wrote:
>>
>>>Hi,
>>>
>>>Try to switch the modepins to JTAG only. Do you use a PC3 clone? There
>>>seems to be some problems in certain impact versions with PC3 and S3 if
>>>the chip is not in JTAG only mode.
>
>
>>The programmer is an FTDI FT2232 using an homebrew XSVF parser. I
>>believe I've got all the bugs worked out of the software since
>>programming the CPLD goes without a problem.
>
>
> Verify board connections -> Power -> Clocks -> Other.
>
> I think also that if you try to program:
> Onboard USB -> XCF01S eeprom
> eeprom -> FPGA
>
> You add more steps that may fail.
That's why I'm not and didn't mention the eeprom at all at first ;)
> Also you could try to manually read if the contents of the XCF01S is what
> you expect.
>
>
>>it's a XCF04S. I've got some other issues with that one
>>however, it seems that is has some dead banks which is why I'm trying to
>>program the fpga directly in the first place. As far as I can tell these
>>two problems are unrelated.
>
>
> So you need to alter M[0:2] pins to 1-0-1 (ds099 p45).
> And according to table 26 (ds099 p45) you need at least an XCF02S.
> So schematic is contradictive.. :)
>
Since I'm using an XCF04S I have twice the space I really need so I'm
not sure why my schematic is contradictive here. :)
> Your schematic would be easier to follow if you added consistent chip
> identifications ie Ux XC3S400 etc..
>
> Also soldering pads for debug fixes could be something to have in mind for
> later revisions. Assume failure ;)
>
Yeah, that's the big lesson out of all this; use busses and name
everything correctly. You're not the first to be confused by the
schematic. Soldering pads is also a good one, I was stubborn enough not
to add any, which is dumb.
Thanks so far anyway :)
Cheers,
Mike
http://projectvga.org
Article: 128751On Feb 5, 2:20=A0pm, Mike Treseler <mike_trese...@comcast.net> wrote: > FPGA wrote: > > # ** Warning: Design size of 10053 statements or 1 leaf instances > > exceeds ModelSim PE Student Edition recommended capacity. > > # Expect performance to be quite adversely affected. > > How do I fix this problem? > > Remove 53 lines or buy a license. > > =A0 =A0 =A0 -- Mike Treseler I want to add the ieee_proposed library which can be found at http://www.vhdl.org/vhdl-200x/vhdl-200x-ft/packages/files.html . I was unsuccessfull in adding it the last time, so I just copy pasted the files in the current work directory. Now, I am getting warnings that # ** Warning: Design size of 10053 statements or 1 leaf instances exceeds ModelSim PE Student Edition recommended capacity. # Expect performance to be quite adversely affected. I just found out that the packages in ieee_proposed that I added in the work dir are huge and thats what is causing the problem. Please suggest on how to add this library and also if I would still get the same problems with the size even after adding the packages into a library ThanksArticle: 128752
On Feb 5, 3:04 pm, Michael Meeuwisse
<mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com>
wrote:
> Sky46...@trline5.org wrote:
> >>> * Check power for any dips or transients.
>
> >>My VccAux seems to be 2.34V, this is supplied by a lm1086-2.5 so I don't
> >>really know what's causing this (it's just below the minimum required,
> >>isn't it?) or how I can fix it. Vcco is 3.34V and VccInt is 1.20V.
>
> > XC3S400-PQ208
> > http://direct.xilinx.com/bvdocs/publications/ds099.pdf(t31 p58/208)
> > Min Nom Max
> > Vccint 1.140 1.200 1.260
> > Vccaux 2.375 2.500 2.625
> > Vcco 1.140 - 3.450
>
> > LM1086-2.5
> > http://users.ece.utexas.edu/~valvano/Datasheets/LM1086.pdf
> > Min Typ Max
> > Vout 2.450 2.50 2.525 (Vin=4-18V Ifull)
>
> > Current limit: Min=1.5A Typ=2.7A at Vin=8V
>
> > Your Vcco regulator uses "3V3" for Vin with a 10uF capacitor on each input
> > and output.
> > "3V3" comes from S53, S39, S33, S27, S21, C25, C31, C36, C41, C43, C54 on
> > the PCI connector (CON1).
> > (Schematic:http://wacco.mveas.com/img/schema1d.png)
>
> > So the Vin of the 2.5V regulator is not enough.
>
> Yep, I realised that too and got just back from uni where I've got
> better tools than here at home. The Vin is now tied to 5V and the output
> is a clean 2.50V. (Also, I fixed the second led on the CPLD but that's
> irrelevant for this discussion)
>
> Still can't program the fpga though.
>
> > Also there's the issue of voltage ramp time upon startup.
> > Vcco 2000 us
> > Vccaux - us (no requirement)
> > Vccint 500 us
> > (p57 Table 29 Power voltage ramp time requirements)
>
> > So you might need to check Vccint vs Vccaux. The Vccaux should be powered
> > before Vccint, but it's not that sensitive (or?). (see p53)
>
> Hmm, I checked the fpga and it's a revision E with the GQ fabrication
> process code so I guess I'm lucky and don't have to worry about any of this.
>
> > Check that your oscillator does have proper power. And outputs a correct
> > waveform at the XC3S400 input (Bank5 GCLK2, P76).
> > (LVTTL 0.8 - 2.0 swing + flanks)
>
> This is where it gets annoying, I don't have anything to check out the
> waveform with. I'll have to drag everything to uni tomorrow if I want to
> see what's happening on such lines which is a much bigger effort than
> just taking the PCI card - I'll do it anyway, but still. It would be
> easier if I was able to program the fpga so I could fling a little
> counter-thing on it outputting it to the led.
>
>
>
>
>
> >>> * Connect directly with a parallell port jtag adapter.
> >>> Like this:http://www.xilinx.com/support/programr/jtag_cable.pdf
> >>> (And only try the USB approch once it confirmed to work)
>
> >>The thing is, the programmer is embedded on the board itself so
> >>connecting a different programmer would require me to start cutting pcb
> >>traces.
>
> > Measure the output of your onboard usb programmer that it does what you
> > expect it to do. Ie feedback it's TDO to your parallell port.
> > If this fails, try the cut traces approach and solder some wires so you can
> > change programmer at will.
>
> > Also use program directly via JTAG mode to start with, only when that works
> > try eeprom. The first bitstream ("program") should be something simple like
> > pulsing a LED.
>
> Right now the program is exactly (except for pinout of course) the same
> as the thing I flashed succesfully into the CPLD. It had the led tied to
> counter[25] where counter = counter + 1 on every posedge clk. I'm
> completely ignoring the eeprom at the moment.
>
> > (604-00033G-ND IC FTDI2232L USB/SERIAL 48-LQFP)
>
> > Scan chain (reverse order?):
> > FTDI2232L - XC95144XL - XC3S400 - XCF01S - FTDI2232L
>
> It's FTDI tdi -> XCF04S -> XC3S400 -> XC95144XL -> FTDI tdo
>
> >>> * Lower the clocking frequency, try 50 kHz.
>
> >>Didn't seem to help. Afaik there's no minimum clock so I even tried it
> >>at ~100Hz (which takes forever btw, in case you never tried it) but it
> >>still failed.
>
> > Verify bitstream at TDI+TCK?
>
> The CPLD verifies so I'm pretty sure it's not the programmer. I'll do a
> debug output though and check it by hand tonight.
>
> > {M0,M1,M2} = 3'b000 (ds099 p45 for mode table)
>
> > So configuration mode is master serial. Thus CCLK+DIN is the ones that
> > dictates programming. Setting M0=1, M1=0, M2=1 gives you jtag programming
> > mode. Which might make life easier in the beginning. It's also the mode
> > that is smoother to use when developing.
>
> All documentation seems to say that M[2:0] don't matter at all when you
> want to program using JTAG, say, the first line of the chapter "JTAG
> Configuration Mode" of ug332 (page 187).http://www.xilinx.com/support/documentation/user_guides/ug332.pdf
>
>
>
>
>
> >>> * Double check all pins related to configuration (DONE, M0,M1,M2, INIT_B,
> >>> CCLK, etc)
>
> >>M[2:0] are all tied to ground, and changing this would again require
> >>some force so I'd rather not. This shouldn't matter afaik, since you can
> >>always program using JTAG anyway, right? Likewise, when configuring
> >>using JTAG it doesn't matter what CCLK is, does it? I mentioned the
> >>state of INIT_B, PROG_B and DONE earlier.
>
> > M[2:0] = 000 => Master serial mode according to datasheet ds099 page 45.
> > So CCLK will matter. Btw, check if CCLK (2.5V) does output a proper waveform
> > at the eeprom input (Pin3 CLK). And that eeprom output is correct at the fpga.
>
> > Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V
>
> Sorry you lost me - is this a problem? I followed figure 4 of xapp453 to
> enable 3.3V powered programming;http://www.xilinx.com/support/documentation/application_notes/xapp453...
> Rpar is R24 in case you can't find it in my (unfortunately somewhat
> confusing) schematic.
>
> The only changes I made is the DONE pin connection because I want to
> imitate the behavior of Figure 1 of xapp694, which makes it possible to
> use parts of the eeprom for user data.http://www.xilinx.com/support/documentation/application_notes/xapp694...
>
> > Signals:
> > INIT_B Shall go high after memory is cleared. And shall not be tied low.
>
> Is low, goes high when programming starts, goes back to low after that> PROG_B Goes high?
> Always high
> > DONE Goes high after configuration is complete.
> Always low
> > HSWAP_EN Is tied low in your schematic => Pullup resistors enabled on all
> > pins not activly involved in the configuration process.
> > Check that no pullup'ed pin interfere with the configuration process.
> > (ds099 p101)
>
> I wouldn't know which one besides the ones already mentioned. The only
> user IO pin that's connected to any of these is P102 (bank 4) which is
> tied to CCLK so I can clock out user data at a later point after
> configuration. A pull-up on CCLK shouldn't matter afaik.
>
>
>
> > You might use these to find out what's going on.
>
> >>> * You could connect pins to the fpga DIN etc.. back to your PC to verify your
> >>> fpga actually get the data you expect.
>
> >>Would data pushed in through JTAG appear on DIN? I could write something
> >>that checks TDO but I'm told the spartan spits out zeroes or other
> >>nonsense when I'm shifting data in.
>
> > My idea was to attach a wire directly to TDI/TDO + TCK back into an INPUT pin
> > of the parallell port to verify data.
>
> Hmm. Not sure if that's possible, I'd need at least a tool to sample the
> parallel port correctly. I'll check the data I'm sending to the FTDI
> first, maybe something odd is happening in there.
>
>
>
> >>Thorsten Trenz wrote:
>
> >>>Hi,
>
> >>>Try to switch the modepins to JTAG only. Do you use a PC3 clone? There
> >>>seems to be some problems in certain impact versions with PC3 and S3 if
> >>>the chip is not in JTAG only mode.
>
> >>The programmer is an FTDI FT2232 using an homebrew XSVF parser. I
> >>believe I've got all the bugs worked out of the software since
> >>programming the CPLD goes without a problem.
>
> > Verify board connections -> Power -> Clocks -> Other.
>
> > I think also that if you try to program:
> > Onboard USB -> XCF01S eeprom
> > eeprom -> FPGA
>
> > You add more steps that may fail.
>
> That's why I'm not and didn't mention the eeprom at all at first ;)
>
> > Also you could try to manually read if the contents of the XCF01S is what
> > you expect.
>
> >>it's a XCF04S. I've got some other issues with that one
> >>however, it seems that is has some dead banks which is why I'm trying to
> >>program the fpga directly in the first place. As far as I can tell these
> >>two problems are unrelated.
>
> > So you need to alter M[0:2] pins to 1-0-1 (ds099 p45).
> > And according to table 26 (ds099 p45) you need at least an XCF02S.
> > So schematic is contradictive.. :)
>
> Since I'm using an XCF04S I have twice the space I really need so I'm
> not sure why my schematic is contradictive here. :)
>
> > Your schematic would be easier to follow if you added consistent chip
> > identifications ie Ux XC3S400 etc..
>
> > Also soldering pads for debug fixes could be something to have in mind for
> > later revisions. Assume failure ;)
>
> Yeah, that's the big lesson out of all this; use busses and name
> everything correctly. You're not the first to be confused by the
> schematic. Soldering pads is also a good one, I was stubborn enough not
> to add any, which is dumb.
>
> Thanks so far anyway :)
>
> Cheers,
>
> Mikehttp://projectvga.org
I would still recommend trying to get the XCF04S out of the loop.
As I mentioned before, there are known issues with the serial
data stream from the PlatformFlash interfering with JTAG programming.
Perhaps you could unsolder the part and just wire from its TDI
to TDO pin. You may need to generate new SVF files for the shorter
chain, but I think it's worth a try since everything else has
failed...
Regards,
Gabor
Article: 128753
Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote:
>Still can't program the fpga though.
>> Check that your oscillator does have proper power. And outputs a correct
>> waveform at the XC3S400 input (Bank5 GCLK2, P76).
>> (LVTTL 0.8 - 2.0 swing + flanks)
>This is where it gets annoying, I don't have anything to check out the
>waveform with. I'll have to drag everything to uni tomorrow if I want to
>see what's happening on such lines which is a much bigger effort than
>just taking the PCI card - I'll do it anyway, but still. It would be
>easier if I was able to program the fpga so I could fling a little
>counter-thing on it outputting it to the led.
You could also use a "divide by N" approach so you can get an estimate that the
oscillator work properly.
>> Also use program directly via JTAG mode to start with, only when that works
>> try eeprom. The first bitstream ("program") should be something simple like
>> pulsing a LED.
>Right now the program is exactly (except for pinout of course) the same
>as the thing I flashed succesfully into the CPLD. It had the led tied to
>counter[25] where counter = counter + 1 on every posedge clk. I'm
>completely ignoring the eeprom at the moment.
You could try this for an arbitrary divide by N:
if( count < 10000000 )
count = count + 1;
else
begin
count = 0;
led_buffer = led_buffer ^ 1;
end
>It's FTDI tdi -> XCF04S -> XC3S400 -> XC95144XL -> FTDI tdo
All TDO/TDIs with all outputs wired to inputs ..?
>All documentation seems to say that M[2:0] don't matter at all when you
>want to program using JTAG, say, the first line of the chapter "JTAG
>Configuration Mode" of ug332 (page 187).
>http://www.xilinx.com/support/documentation/user_guides/ug332.pdf
"Spartan"-3 Generation FPGAs have a dedicated four-wire IEEE 1149.1/1532 JTAG
port that is always available any time the FPGA is powered and regardless of
the mode pin settings. However, when the FPGA mode pins are set for JTAG mode
(M[2:0] = <1:0:1>), the FPGA waits to be configured via the JTAG port after a
power-on event or after PROG_B is pulsed Low."
(ug332 p187)
The JTAG *interface* is available at all times. But the FPGA will only be
configured by JTAG if the mode pins are M[2:0] = 101.
(An exception might by with JSTART instruction, but I'm not sure).
>> Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V
>Sorry you lost me - is this a problem? I followed figure 4 of xapp453 to
>enable 3.3V powered programming;
>http://www.xilinx.com/support/documentation/application_notes/xapp453.pdf
>Rpar is R24 in case you can't find it in my (unfortunately somewhat
>confusing) schematic.
I might be wrong on this, but CCLK ought to be LVCMOS25 and the XCF04S ought
to be LVTTL. Thus voltage levels might mismatch if you'r unlucky.
LVCMOS25 Vil=0.7 Vih=1.7
LVTTL Vil=0.8 Vih=2.0
(ds099 p61)
>I wouldn't know which one besides the ones already mentioned. The only
>user IO pin that's connected to any of these is P102 (bank 4) which is
>tied to CCLK so I can clock out user data at a later point after
>configuration. A pull-up on CCLK shouldn't matter afaik.
You have also set HSWAP_EN to low. This might affect.
>> My idea was to attach a wire directly to TDI/TDO + TCK back into an
>> INPUT pin of the parallell port to verify data.
>>
>Hmm. Not sure if that's possible, I'd need at least a tool to sample the
>parallel port correctly. I'll check the data I'm sending to the FTDI
>first, maybe something odd is happening in there.
Ohwell.. it's so easier on the unix side of things ;)
But there are free .dll files on the internet that will make it work on win32.
>That's why I'm not and didn't mention the eeprom at all at first ;)
It's still in the scanchain ;), and in engineering the devil is in the details.
>Since I'm using an XCF04S I have twice the space I really need so I'm
>not sure why my schematic is contradictive here. :)
The schematic have more than one designation for the same chip ;)
Article: 128754Hello, I am looking for a basic simulator which can help me with testing functionalities of my VHDL and Verilog designs. I am running Windows Vista. What would my options be? I am an entry level professional and just need a basic version. Do we have to buy license on yearly basis? Your inputs would be appreciated.Article: 128755
FPGA wrote:
> I just found out that the packages in ieee_proposed that I added in
> the work dir are huge and thats what is causing the problem.
Glad you figured it out.
> Please
> suggest on how to add this library and also if I would still get the
> same problems with the size even after adding the packages into a
> library
It won't matter where the library is.
You are over the limit of the student license,
once you compile it into any library.
Pick a simpler project or call Mentor.
-- Mike Treseler
Article: 128756On Feb 5, 4:52=A0pm, Mike Treseler <mike_trese...@comcast.net> wrote: > FPGA wrote: > > I just found out that the packages in ieee_proposed that I added in > > the work dir are huge and thats what is causing the problem. > > Glad you figured it out. > > > Please > > suggest on how to add this library and also if I would still get the > > same problems with the size even after adding the packages into a > > library > > It won't matter where the library is. > You are over the limit of the student license, > once you compile it into any library. > Pick a simpler project or call Mentor. > > =A0 =A0 =A0 =A0-- Mike Treseler Which tol do you suggest I use. I work on VHDL and Verilog. I need something very basic.Article: 128757
FPGA wrote:
> I am looking for a basic simulator which can help me with testing
> functionalities of my VHDL and Verilog designs. I am running Windows
> Vista. What would my options be?
for basic vhdl see
http://www.symphonyeda.com/shopping.htm
> Do we have to buy license on yearly basis?
Usually.
-- Mike Treseler
Article: 128758
Sky465nm@trline5.org wrote:
> Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote:
>
>
>>Still can't program the fpga though.
>
>
>>>Check that your oscillator does have proper power. And outputs a correct
>>>waveform at the XC3S400 input (Bank5 GCLK2, P76).
>>>(LVTTL 0.8 - 2.0 swing + flanks)
>
>
>>This is where it gets annoying, I don't have anything to check out the
>>waveform with. I'll have to drag everything to uni tomorrow if I want to
>>see what's happening on such lines which is a much bigger effort than
>>just taking the PCI card - I'll do it anyway, but still. It would be
>>easier if I was able to program the fpga so I could fling a little
>>counter-thing on it outputting it to the led.
>
>
> You could also use a "divide by N" approach so you can get an estimate that the
> oscillator work properly.
>
>
>>>Also use program directly via JTAG mode to start with, only when that works
>>>try eeprom. The first bitstream ("program") should be something simple like
>>>pulsing a LED.
>
>
>>Right now the program is exactly (except for pinout of course) the same
>>as the thing I flashed succesfully into the CPLD. It had the led tied to
>>counter[25] where counter = counter + 1 on every posedge clk. I'm
>>completely ignoring the eeprom at the moment.
>
>
> You could try this for an arbitrary divide by N:
> if( count < 10000000 )
> count = count + 1;
> else
> begin
> count = 0;
> led_buffer = led_buffer ^ 1;
> end
>
I'll try it the moment I can program it ;)
>
>>It's FTDI tdi -> XCF04S -> XC3S400 -> XC95144XL -> FTDI tdo
>
>
> All TDO/TDIs with all outputs wired to inputs ..?
>
>
>>All documentation seems to say that M[2:0] don't matter at all when you
>>want to program using JTAG, say, the first line of the chapter "JTAG
>>Configuration Mode" of ug332 (page 187).
>>http://www.xilinx.com/support/documentation/user_guides/ug332.pdf
>
>
> "Spartan"-3 Generation FPGAs have a dedicated four-wire IEEE 1149.1/1532 JTAG
> port that is always available any time the FPGA is powered and regardless of
> the mode pin settings. However, when the FPGA mode pins are set for JTAG mode
> (M[2:0] = <1:0:1>), the FPGA waits to be configured via the JTAG port after a
> power-on event or after PROG_B is pulsed Low."
> (ug332 p187)
>
> The JTAG *interface* is available at all times. But the FPGA will only be
> configured by JTAG if the mode pins are M[2:0] = 101.
> (An exception might by with JSTART instruction, but I'm not sure).
>
I keep on arguing that it shouldn't matter, but to be absolutely on the
safe side I'll make it possible tomorrow to set M2 and M0 to 2.5V. I
really hope I'm wrong and changing this makes the problems go away.
>
>>>Btw, notice that CCLK is 2.5V, and eeprom output is 3.3V
>
>
>>Sorry you lost me - is this a problem? I followed figure 4 of xapp453 to
>>enable 3.3V powered programming;
>>http://www.xilinx.com/support/documentation/application_notes/xapp453.pdf
>>Rpar is R24 in case you can't find it in my (unfortunately somewhat
>>confusing) schematic.
>
>
> I might be wrong on this, but CCLK ought to be LVCMOS25 and the XCF04S ought
> to be LVTTL. Thus voltage levels might mismatch if you'r unlucky.
> LVCMOS25 Vil=0.7 Vih=1.7
> LVTTL Vil=0.8 Vih=2.0
> (ds099 p61)
>
Good point, it seems the XCF04S wants at least 2.0V according to ds123
when in 3.3V operation. This might be a problem if the fpga can't fully
pull CCLK up to 2.5V. I'll have to check tomorrow.
>
>>I wouldn't know which one besides the ones already mentioned. The only
>>user IO pin that's connected to any of these is P102 (bank 4) which is
>>tied to CCLK so I can clock out user data at a later point after
>>configuration. A pull-up on CCLK shouldn't matter afaik.
>
>
> You have also set HSWAP_EN to low. This might affect.
>
It only seems to affect other IO pins not used during configuration and
when tied low it enables the pull-ups. So only P102 is interesting here,
but shouldn't cause problems. Again, I'll have to see tomorrow what CCLK
is actually doing.
>
>>>My idea was to attach a wire directly to TDI/TDO + TCK back into an
>>>INPUT pin of the parallell port to verify data.
>>>
>>
>>Hmm. Not sure if that's possible, I'd need at least a tool to sample the
>>parallel port correctly. I'll check the data I'm sending to the FTDI
>>first, maybe something odd is happening in there.
>
>
> Ohwell.. it's so easier on the unix side of things ;)
> But there are free .dll files on the internet that will make it work on win32.
>
Har har :)
I'll see what I can do. I haven't gotten to checking the FTDI output yet.
>
>>That's why I'm not and didn't mention the eeprom at all at first ;)
>
>
> It's still in the scanchain ;), and in engineering the devil is in the details.
>
>
>>Since I'm using an XCF04S I have twice the space I really need so I'm
>>not sure why my schematic is contradictive here. :)
>
>
> The schematic have more than one designation for the same chip ;)
>
I've been looking at this schematic for a few months now and it's the
first time I'm noticing it. X__x I'll change it ASAP.
Cheers,
Mike
http://projectvga.org
Article: 128759Gabor schrieb: http://learn.to/quote/ Regards FalkArticle: 128760
Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote:
>Sky465nm@trline5.org wrote:
>> Michael Meeuwisse <mickeymeeuw@nospamplease_thesearchcompanywithcolorfulletters'emailservice.com> wrote:
>> I might be wrong on this, but CCLK ought to be LVCMOS25 and the XCF04S ought
>> to be LVTTL. Thus voltage levels might mismatch if you'r unlucky.
>> LVCMOS25 Vil=0.7 Vih=1.7
>> LVTTL Vil=0.8 Vih=2.0
>> (ds099 p61)
>>
>Good point, it seems the XCF04S wants at least 2.0V according to ds123
>when in 3.3V operation. This might be a problem if the fpga can't fully
>pull CCLK up to 2.5V. I'll have to check tomorrow.
I checked the datasheet again, and you'r in the clear because:
Output of LVCMOS25: Vol=0.4 Voh=Vcco-0.4 => Voh=2.1
(ds099 p62)
Input of LVTTL: Vil=0.8 Vih=2.0
Input of LVCMOS33: Vil=0.8 Vih=2.0
But with a 0.1V margin by definition! So good signal is a must.
Btw, I'm going to check if JTAG configuration works in non-jtag mode. Might
be useful to know.
Article: 128761On Feb 6, 4:13 am, Xesium <amirhossein.gholamip...@gmail.com> wrote: > Dave, > Thanks so much. Actually removing -target mdm worked! > I feel dumb to have spent weeks trying to fix this issue! But at least > it is working now! > > Thanks a lot again, > > Amir > > On Feb 4, 11:26 pm, David <simianfe...@gmail.com> wrote: > > > > I actually tried this command: > > > $ xmd -tcl genace.tcl -jprog -hw implementation/download.bit -board > > > ml310 -target mdm -elf timer_test/executable.elf -ace system.ace > > > > My software code is supposed to write something to hyperterminal > > > through RS232 port and I have in fact populated the local BRAMs with > > > the data and instructions of my software code and download.bit should > > > contain that information (I tried commands with and without -elf > > > timer_test/executable.elf). > > > Did you try removing the "-target mdm" as well? If your program is in > > bram it shouldn't be necessary. > > > > Firstly I don't know why it is so, secondly I know no more convenient > > > way to make sure that my design is actually loaded and working (the > > > only way I found convenient is to write something to the output)! > > > You could try a very simple design in ISE that just flashes a led or > > something and make an ace file from that. That should at least tell > > you whether it is a problem with the systemAce or the microblaze. > > > Also, re-reading your original post - you probably don't need the OPB > > SysAce controller unless you intend to write to the compact flash - it > > could be causing some conflict with the sysace chip if it's not set up > > properly. > > > Cheers, > > Dave No problem Amir. I suspect that the -target mdm switch was stopping the mircroblaze, in much the same way as it stops when you connect to it with xmd. DaveArticle: 128762
Has anyone successfully ported Petalinux in Microblaze (ML505) and used the SATA AHCI driver? Is the AHCI driver from Petalinux distribution working OK?Article: 128763
I posted this on the Xilinx EDK forum without success so far. I recently upgraded to EDK 9.2.02i and built up the TestApp_Peripheral executable for the Xilinx Spartan-3E Starter Board Rev D. I can run the exe OK but I am having problems getting GDB to talk to it. The reason for testing GDB on this app was to ensure that GDB was working properly before tackling another more complex application under development. I have set the -g and -O0 option for both library generation as well as the TestApp_Peripheral application. When I run GDB, GDB opens, then when I press the RUN icon, GDB appears to download the application as indicated by the progress bar at the bottom right of the screen but the target selection dialog box is again immediately again displayed. The RUN icon is grayed out. In the xbash console window, the following pair of messages is shown Info: Accepted a new GDB connection from 127.0.0.1 on port 2195 System Reset ........DONE Info: Closed the GDB connection from 127.0.0.1 on port 2195 Error: Connection terminated by client. Is there a problem with GDB with this EDK version or am I doing something wrong? I have searched the Xilinx archives! Any help appreciated, John RobbinsArticle: 128764
<fpgaasicdesigner@gmail.com> wrote in message news:280550e4-9ea6-42ae-9769-fdf8f4a48fe4@d4g2000prg.googlegroups.com... > Hi all, > > I would like to know how we can demodulate a BPSK signal with CORDIC > algorithm. > How can we (with CORDIC) make the phase acquisition and tracking due > to an IQ conversion without a Costas Loop... > A proper place for this kind of question is comp.dsp. /MMArticle: 128765
On 5 Feb, 15:04, Gabor <ga...@alacron.com> wrote: > On Feb 5, 3:02 am, "Marco T." <marcotos...@gmail.com> wrote: > > > Hallo to everyone, > > I should develop a system which outputs a pwm signal into a filter to > > obtain a sine at 500 Hz which will command a class D amplifier. > > > I was considering to use dds compiler to generate digital sine, then > > putting the output in a pwm generator, like the one seen in fpga4fun > > website. > > > If I can't use a high frequency oscillator for fpga, because of the > > limit of class D amplifier, may I use an oscillator of 500kHz about? > > > There are some troubles, in example with DCM? > > > Many Thanks, > > Marco > > Generating a "digital sine wave" requires a clock frequency higher > than the output waveform. The clock oscillator for the FPGA can > be at many MHz, allowing the sine wave to have many samples per > waveform period. This is how you get a smooth wave without > resorting to a very tight low-pass filter on the output. > > You can also create the PWM waveform inside the FPGA, which > would remove your analog filtering requirements on the sine > wave, but would require an even higher clock frequency to > achieve a reasonable duty cycle resolution. The frequency > limit of the class D amplifier is only on the output frequency > of the PWM, not the oversampling clock used to generate > the waveform. > > Regards, > Gabor My aim is to create an output from one fpga pin which will be a pwm sine. This signal will be amplified using a class D amplifier to obtain a 200 Volt with 3 amperes output, so if minimum high time of that signal is 50ns (considering a 50% duty cycle of a 10MHz clock), and the transistor of amplifier have lower band, in which way may I amplify that signal? I don't know power amplifiers, but I think that 10 MHz switching it's very very high. Thanks, MarcoArticle: 128766
jcr_alr@xplornet.com schrieb: > I posted this on the Xilinx EDK forum without success so far. > > I recently upgraded to EDK 9.2.02i and built up the TestApp_Peripheral > executable for the Xilinx Spartan-3E Starter Board Rev D. I can run > the exe OK but I am having problems getting GDB to talk to it. The > reason for testing GDB on this app was to ensure that GDB was working > properly before tackling another more complex application under > development. > > I have set the -g and -O0 option for both library generation as well > as the TestApp_Peripheral application. > > When I run GDB, GDB opens, then when I press the RUN icon, GDB appears > to download the application as indicated by the progress bar at the > bottom right of the screen but the target selection dialog box is > again immediately again displayed. The RUN icon is grayed out. > > In the xbash console window, the following pair of messages is shown > > Info: Accepted a new GDB connection from 127.0.0.1 on port 2195 > System Reset ........DONE > > Info: > Closed the GDB connection from 127.0.0.1 on port 2195 > Error: Connection terminated by client. > > > Is there a problem with GDB with this EDK version or am I doing > something wrong? > > I have searched the Xilinx archives! > > Any help appreciated, > > John Robbins I have a similar problem. I am using also EDK 9.2 (on Linux). I can connect to the embedded Microblaze with xmd (the basic commands work), but I can not download or debug anything with gdb. -MarkusArticle: 128767
Hello all. below is a part of my code for an OPB timer attached to a
Microblaze with no inerrupts. the timer counts correct but when
reaches the value 0xFFFFFFFF ( end point) should roll over and start
again counting but this doesn't happend. what might be wrong here?
#include "xparameters.h"
#include "xstatus.h"
#include "xtmrctr_l.h"
#define TMRCTR_BASEADDR XPAR_OPB_TIMER_1_BASEADDR
#define TIMER_COUNTER_0 0
int main(void) {
Xuint32 *memloc;
Xuint32 Value1;
Xuint32 Value2;
Xuint32 *TimerCurrentValue;
Xuint32 ControlStatus;
Xuint32 TmrCtrBaseAddress;
Xuint32 HasEventOccurred;
Xuint8 TmrCtrNumber;
XTmrCtr_mSetControlStatusReg(TmrCtrBaseAddress, TmrCtrNumber,0x0);
/*
* Set the value that is loaded into the timer counter and cause
it to
* be loaded into the timer counter
*/
XTmrCtr_mSetLoadReg(TmrCtrBaseAddress, TmrCtrNumber, 0xFFFFF000);
XTmrCtr_mLoadTimerCounterReg(TmrCtrBaseAddress, TmrCtrNumber);
/*
* Clear the Load Timer bit in the Control Status Register
*/
ControlStatus = XTmrCtr_mGetControlStatusReg(TmrCtrBaseAddress,
TmrCtrNumber);
XTmrCtr_mSetControlStatusReg(TmrCtrBaseAddress,
TmrCtrNumber,ControlStatus & (~XTC_CSR_LOAD_MASK ));
/*
* Start the timer counter such that it's incrementing by default
*/
XTmrCtr_mEnable(TmrCtrBaseAddress, TmrCtrNumber);
thank you all
Xenix
Article: 128768Hi! I have implemented the Dallas/Maxim 1-Wire master DS1WM (version v1.100) in a Spartan3A. It works fine most of the times, but in some implementations it just won't work. Changing something silly in another part of the FPGA (like the version number that we have stored in a register) usually helps and in the next implementation it works again. Moreover, even in an implementation where it seems to work most of the time, it sometimes hangs at start-up. In those cases, resetting the design and staring over seems to do the trick. I haven't had the time to dig into what actually goes wrong in these cases but before I spend too much time in the lab I thought I'd check in the library. In my design, the control and status registers of the DS1WM are mapped into the register map of a small MCU and in doing so I had to do away with the bi-directional data bus, so I made some modifications to the original code as supplied by Dallas/Maxim. The modifications were trivial so I don't beleive they are able to cause the problems. Since the module is clocked by the same clock as the rest of the MCU interface (a 48MHz global clock covered by a PERIOD constraint in the .ucf file), timing problems should not pass undetected. Anyone with experience of the DS1WM, any pit-falls that you know of that I might have fallen into? Serching this group for DS1WM does not return any hits, and 1-Wire is almost as meager... Regards, /Lars P.S. Remove the obvious in you want to email me directly. D.S.Article: 128769
Hi, > All documentation seems to say that M[2:0] don't matter at all when you > want to program using JTAG, say, the first line of the chapter "JTAG > Configuration Mode" of ug332 (page 187). > http://www.xilinx.com/support/documentation/user_guides/ug332.pdf Maybe, but our experience shows, that this is not always true. We had a board, which programmed fine with HW-USB, but failed in a similar way like yours with PC3. Choosing JTAG only solved the problem. best regards Thorsten Trenz -- www.trenz-electronic.deArticle: 128770
Hi everyone, I'm running Webpack ISE 9.2i (just updated to 9.2.04i/J40) on Suse10.1. This is not the 'blessed' RedHat but so far, this has worked great for compiling simple VHDL and putting it on a Spartan 3 kit. I'd like to learn how to properly simulate my designs though, and I've tried to implement the 'Design Simulation' chapter from the ISE 9.2i Quickstart (which is actually the 9.1i quickstart): http://toolbox.xilinx.com/docsan/xilinx92/books/docs/qst/qst.pdf So I have created a counter.vhd, a testbench etc. all according to the manual. When I click 'check syntax' for the VHDL file, no errors or warnings are returned. However, trying to actually simulate the design returns "Simulator error Parsing "counter_beh.prj": 0.02 Building counter_isim_beh.exe ERROR:Simulator:607 - ISE Simulator is unable to elaborate this design due to specific coding constructs used in the design. Xilinx is actively working on reducing the number of conditions where this error occurs. For more information on this error, please consult Answer Record 24067 in Answers Database at http://www.xilinx.com/support. I did of course look at the answer record in question, but none of the answers seem to apply to this case - one would assume that Xilinx's simple design isn't triggering such conditions anyway. I've already googled a bit, and renamed the 'ld' commands in the Xilinx gcc subdirectories, but that didn't help. There are other Linux users with this same problem, but I've not found a solution so far. Does anyone know how to get the simulation to work? Otherwise - how can I run the simulation from the command-line so I can get a better idea of what it's trying to compile and where things are going wrong? One thing that I noticed is that it's apparently trying to create an .exe file, which wouldn't be suitable for a Linux platform. Regards, Paul Boven. P.S.: Yes, I'm aware that only RH is supported by Xilinx - but only Suse is supported by my employer :-)Article: 128771
Hi
I have a strange bug in my simulation and cant figure out the error.
I have a simple ram that contains data that should be read as described
in the following process:
PROC_ram : process (clk)
begin
if (clk'event and clk = '1') then
-- memory write:
if (ew_cp0 = '1') then
ram(conv_integer(unsigned(rw_addr_cp0))) <= data_in_cp0;
end if;
if (rst = '0') then -- optional reset
data_out_cp0 <= (others => '0');
else
data_out_cp0 <= ram(conv_integer(unsigned(rw_addr_cp0)));
end if;
end if;
end process PROC_ram;
The problem that I have is, that the data is output with a delay of one
cycle. So when I check the waveforms I see that on a rising edge of the
clock the address changes to one for instance, but the data is still
read from memory position zero...
Anyone an idea what could be wrong here?
Many thanks!
Article: 128772
Stupid me, I should have an asynchronous read....
Now it looks like this:
PROC_ram : process (clk)
begin
if (clk'event and clk = '1') then
-- memory write:
if (ew_cp0 = '1') then
ram(conv_integer(unsigned(rw_addr_cp0))) <= data_in_cp0;
end if;
if (rst = '0') then -- optional reset
--data_out_cp0 <= (others => '0');
-- else
--data_out_cp0 <= ram(conv_integer(unsigned(rw_addr_cp0)));
end if;
end if;
end process PROC_ram;
data_out_cp0 <= ram(conv_integer(unsigned(rw_addr_cp0)));
In this case the reset port can be omitted, I wanna sythesis this as a
BRAM on a Xilinx FPGA. Hope that works!
Article: 128773Marco, You may use the FPGA to create a square wave in a fixed frequency (say 50KHz) and variable duty cycle. This duty cycle variation you do using a counter and the step it changes will be your resolution. If you use a 10MHz clock in the counter you can get up to 199 steps. A 50MHz clock would give you near 10bits. Use a table (like a BlockRAM - in Spartan3 family you get a 1Kx16 RAM that you can innitialize and read as a ROM) to output the dutycycle variation in order to shape your sine. Now, use a filter (Bessel or other - even a RC filter can give you good results in your first try) to get the energy on every square wave translated to a voltage. The fixed base frequency helps to tune the filter precisely and get a higher resolution. In order to get a correct Vpp in the filter's output (as well as a lower impedance) you may have to use an Operational Amplifier such as LF347 type. The output of the filter you will inject in your amplifier. Don't forget you may need an AC coupling to the amplifier and you can get it using a simple electrolitic capacitor between the filter and amplifier's input. -AugustoArticle: 128774
Of course, the rate you read the table will be the rate the voltage changes in the output, giving you the frequency of the generated signal. In order to reduce distortion you must keep the reading rate less than the square wave frequency. In the given example you cannot read faster than 50KHz. For a 64 point sine wave and reading the table at 49.9KHz gives you 779,69Hz in the output. If you want a 500Hz signal with 128 points you must read at 64KHz. So, you can reduce the precision of the sine wave to less than 100 points or increase the square wave frequency to over 64KHz. -Augusto
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