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
Test01,
Choose GTLP as the driver. Place the 60 ohm pullup to 1.8 volts at the
receiver end. No series resistor at all.
Rise time is: 1.4 V/ns
Fall time is: 4.1 V/ns
No discontinuities, no steps.
Simulated with Hyperlynx.
1.8 volts
Driver impedance: 8.9 ohms. |
60 ohms
60 ohm pcb trace |
GTLP ----=========================---|--to receiver io pin on ?
Austin
Test01 wrote:
> Austin,
>
> yes. from FPGA LVCMOSS33 Open drain output, I have 60 Ohm tranmission line and then to 150 Ohm pull-up to 1.8V and then from there to 100 Ohm series resistor to the load. By looking at the waveform, we are seeing some ledges (steps) on the rising edge.
>
> My solution to acheive better slew rate will be to lower the pull-up resistor value down to 60 Ohms and lower the series termination down to 22 Ohms. 60 Ohm pull-up termination will be close to the tranmsmission line impedance of 60 Ohms. By looking at the V-I curve the bottom transistor voltage drop is about 200mV at 15.6 mA. This translates to only 12.8 Ohms of ON resistance. Thus I can afford to lower the pull-up resistor down to 60 Ohms. This will still give me 400mV low swing.
>
> Is that correct?
Article: 119926Pablo Bleyer Kocik wrote: >> http://www.latticesemi.com/Mico8 > Jim, the link is broken. http://www.latticesemi.com/mico8 is the correct link. > What kind of table are you referring to? Ressource usage (i.e. number of slices, registers and such) depending on what FPGA is used and what features are implemented. cu, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 119927
No, the USER1 and USER2 registers are built in. For the intructions to access those registers, search for the desired register's name in the BSDL file. The cell isn't virtual, it's there all the time, but the length can be viewed as arbitrary including 0 length. ---Matthew Hicks > I've a question concerning BSCAN_SPARTAN3 primitive - since it adds > "virtual" cell to the boundary scan register, do I have to include it > somehow in the BSDL file, that describes the Boundary Scan Register of > my chip? > > Chris >Article: 119928
X-Fest is a very successful and highly technical seminar series, given in 92 cities worldwide. For the June 5, 12, and 14 seminars in three German locations, I will give the keynote address. Come and learn for a full day, “auf deutsch” For details, and to register, click on: http://eetimes.eu/design/199500991 http://www.em.avnet.com/xfest/xlx Peter Alfke, Xilinx Applications, with apologies for this commercial message.Article: 119929
Brian Drummond wrote: > "it is not thought wise to design for higher speeds than this as yet" > http://www.alanturing.net/turing_archive/archive/p/p01/P01-001.html > (from 1945) That's on page 3. Another funny sentence, describingthe architecture: "Erasible memory units of fairly large capacity, to be known as dynamic storage (DS). Probable consisting of between 50 and 500 mercury tanks with a capacity of about 1000 digits each." "digit" here means binary digit, so this will be about 0.04 per mill of my current PC main memory. The interesting thing is the instruction set, but it is very difficult to extract it from the document, because it is a mix of proposals and detailed descriptions of which registers to use for which arithmetic operations. Is there any documentation of the actually running system? If possible, as a modern, pure functional, description, without describing the problems and architecture of mercury delay lines :-) -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 119930
As per my understanding GTLP output requires uses of VREF input pin in corresponding fpga bank. All the VREF pins are used up as I/O pins so I am not sure if I can use the GTLP output. Is that correct? Thanks.Article: 119931
On May 29, 7:35 pm, Patrick Dubois <prdub...@gmail.com> wrote:
> On 29 mai, 05:08, Guru <ales.gor...@email.si> wrote:
>
>
>
> > Hi Patrick,
>
> > I am working with a FX12 MiniModule and MPMC2. I have tried lots of
> > variations for FLASH booting. I have not implemented OPB_EMC in my
> > latest design (under EDK 9.1) since I have not enough logic resources.
> > My experience from EDK 8.2:
> > in core connect architecture (no MPMC2) Flashwriter and booting works
> > with OPB_EMC and PLB_EMC (uses more logic resources). The
> > Flashwriter.tcl had to be modified from 8.1 to 8.2 because some of the
> > functions changed. In MPMC2 architecture the Flashwriter fails but I
> > was able to boot from flash if programmed from other HW (i.e.
> > CoreConnect).
> > If you find any more detail please let me know.
>
> > Cheers,
>
> > Guru
>
> I should have been more precise, it is indeed the Flashwriter that
> fails. Your idea of using a different architecture for the Flashwriter
> part is very good, I should have thought of that. I just tried an
> architecture without MPMC2 (the ref design from Avnet mentionned above
> actually) and not surprinsingly, Flashwriter works.
>
> Now going back to the MPMC2 design however, the bootloader fails in a
> strange way. It successfully loads the whole program into DDR but
> fails at the very last memcpy. This is the memcpy that copies the
> address of the beginning of the program to 0xFFFFFFFC. For some
> strange reason, the program never returns from that call to memcpy.
>
> I verified with a memory dump that the MPMC2 architecture can
> succesfully read without error the whole program in flash. The dump is
> exactly the same as my .srec file.
>
> I am puzzled by this.
>
> Patrick
Patrick,
I think I know what the problem is ! Did you specify in bootloader's
linker script where to boot after reading from flash?
It looks like his:
.boot0 :
{
*(.boot0)
_end = .;
} > ddr
.boot : { *(.boot) } > ddr
I hope it will boot properly :)
Cheers,
Guru
Article: 119932Let me rephrase the question: assuming that TAP controller is in some other state than TEST_LOGIC/RESET is it right that whole FPGA is now clocked with TCK clock instead of system main clock?Article: 119933
Test01, If you use an output, you don't care about the Vref pins, which are ONLY used for GTLP inputs. No GTLP inputs, no need for Vref pins. GTLP output (only), no Vref pins needed, or used. Vref is ONLY used for inputs of HSTL, SSTL, and GTP, GTLP. OK? AustinArticle: 119934
greywolf82@hotmail.it wrote: > I'm working with a board MPC8548CDS-like (PowerPC). Connected to > processor local bus and with pci express there is a Virtex 4 > (xc4vfx60). Hopefully the board vendor has also provided a PCI-express interface core for the FPGA. You will need to customise / use this core, define the PCI BAR (base address register) functionality, and then write a standard linux driver to talk to the FPGA as though it were any PCI / PCI-e device. The process of configuring the FPGA over PCI will be entirely board dependent, talk to your vendor or HW designer! Regards, JohnArticle: 119935
Hi Dave, Dave wrote: > I bought an SZ010 board for use in a PVR project, thinking the EDK/Linux > design would provide a fast development route. In the end this proved > impractical, simply because uCLinux running on a Microblaze (which maxes out > at about 52MHz in this case) doesn't provide good enough network > performance - from memory, an ftp test was clocking in at around 3 mbits/s. The Suzaku's interface to the off-chip MAC-PHY has no DMA capability, which goes a long way to explaining the poor ethernet throughput you describe. With the Xilinx EMAC, and DMA, checksum offload and all bells and whistles we've hit 50mbit/sec with MicroBlaze / uClinux systems in netperf tests. Just to put the record straight... Regards, JohnArticle: 119936
Pablo Bleyer Kocik wrote: >> >>http://www.latticesemi.com/Mico8 >> >>-jg > > > Jim, the link is broken. Oops, try http://www.latticesemi.com/mico8 On the page that jumps to, they tabulate Device LUTs Registers SLICEs f MAX (MHz) I thought a similar simple summary would be good for your core, too? What kind of table are you referring to? > PacoBlaze has been written from scratch following Xilinx's > documentation of their PicoBlaze processor, so any resource > configuration (registers, instructions, scratchpad memory) applies to > PacoBlaze. The only exception are my own extensions for PacoBlaze3m > (16-bit ALU with multiplier). > > Regards. >Article: 119937
On May 26, 8:11 pm, SKatsy...@gmail.com wrote: > On May 25, 5:23 am, futz...@gmail.com wrote: > > > I think I have a problem with my Cyclone II FPGA and wanted to do a > > boundary scan check on the device to see if it is working ok. I looked > > for options to perform a boundary scan check using the Quartus > > programmer tool and couldn't find anything useful. I have used this > > feature on the Xilinx ISE tools and wanted to know if this can be done > > on the Altera FPGAs. > > > Any suggestions will help. > > Thanks > > Anup > > You may try these programs for manual boundary-scan test: > > Scanseer --www.scanseer.com > UniversalScan --www.universalscan.com > > They both allows to monitor and control device's pins in real-time > using JTAG. > > -- SK Thanks to everyone. Cheers AnupArticle: 119938
Frank Buss wrote: > I've implemented a first version of a 6502 core. It has a very simple > architecture: First the command is read and then for every command a list > of microcodes are executed, controlled by a state machine. To avoid the > redundant VHDL typing, the VHDL code is generated with a Lisp program: > > http://www.frank-buss.de/vhdl/cpu.lisp > > This is the output: > > http://www.frank-buss.de/vhdl/t_rex_test.vhdl > > I've tested some instructions, like LDA, and looks like it works, but I'm > sure there are many bugs and not all features are implemented (e.g. BCD > mode or interrupt handling). It uses 2,960 LEs with Quartus 7.1, which is > too much compared to the 797 LEs of the T65 project. Any ideas how to > improve it? My idea was, that the synthesizer would be able to merge the > addressing mode implementations for the commands, but maybe this has to be > refactored by hand. > > My goal is to beat the T65 project in LE usage. Speed and 100% > compatibility with the original 6502 (e.g. the strange S0 and V-flag > feature or the original hardware reset vectors) is not important for me, > but code compiled with http://www.cc65.org/ must work. > > Most FPGAs have some kbyte memory (>5 kByte, even for inexpensive FPGAs, > freely configurable as ROM and RAM), so maybe a good idea would be to store > some microcode in memory? What instruction set is useful to implement the > 6502 instruction set? Maybe a Forth-like microcode? > > Any ideas how to improve the Lisp code? I like my idea of using a lambda > function in addressing-commands, because this looks more clean than a > macro, which I've tried first, but I don't like the explicit call of > emit-lines. How can I refactor it to a more DSL like approach? > Somewhere around here I have a (very old) reference manual for the 6502 - one of my all time favourite processors - that actually listed the instruction decode by bit positions. I'll have to dig it out and amuse myself by writing some code to actually do the decode using straight combinational logic ;) Cheers PeteSArticle: 119939
I recently built a prototype using a xilinx spartan-iie specifically the xc2s150e-fgg456 which is programmed with an xcf02s prom. I have the prom connected first in the jtag chain. I am unable to detect the fpga. If i "tap" the tdo of the prom i can detect and program it fine, but the tdo of the fpga is always floating. I found an error in my design where the program pin, which is connected to the cf pin on the prom, is pulled high with a 4k7 resistor. I have tried pulling it low to no avail. I am able to access the tdo solderball from the side, so i know it is not a bad connection. Also, while programming the prom, the fpga seems to randomly pull outputs high/low about once every second. I'm not sure how this is possible, but it would indicate to me that the data stream is able to cause a reset of the chip. Does anyone know how i can get further information on the problem, or have any ideas what the problem could be? Thanks in advance for any help.Article: 119940
Hi All, PlanAhead 9.1 has been enhanced to have a Pin Planning environment. You can download this tool at www.xilinx.com/planahead. A flexlm based license is required to use PlanAhead, but you can get this for free for a month using the "eval" button on the page. For the specific functionality you are looking for: 0. Create a PlanAhead project 1. Tools->Open PinAhead... 2. Flatten the table in I/O ports table (toggle the group by interfaces/busses button on the side of this table) 3. Select all I/O ports in the I/O ports and right mouse button to "Configure Ports..." 4. Change the I/O standard to LVTTL 5. File->Export Floorplan to get the UCF out. Regards, Salil "Marlboro" <ccon67@netscape.net> wrote in message news:1180118517.266937.134110@q69g2000hsb.googlegroups.com... > Oh yes, it rings the bell by using wild card *, but I will use it with > some prefixs > > NET XYZ* IOSTANDARD = LVTTL; > > The 100% wild card " INST * " generate tons of warnings, it takes > almost forever :) > > Thanks, > > On May 25, 10:33 am, "John_H" <newsgr...@johnhandwork.com> wrote: >> "Marlboro" <cco...@netscape.net> wrote in message >> >> news:1180106384.340327.14150@p47g2000hsd.googlegroups.com... >> >> > Hi, >> >> > Is there a quick way to constraint all IO to the same standard? The >> > default for Spartan3 is LVCMOS25 but we want them to be LVTTL. I know >> > I can do it by constraint one by one, but we have several hundreds >> > pins... >> >> > Thanks, >> >> Two things to try (there may be warnings or errors for either or both): >> >> INST * IOSTANDARD LVTTL; >> INST PADS(*) IOSTANDARD LVTTL; >> >> The synthesizers will sometimes allow a global IOSTANDARD default such as >> the syn_pad_type attribute in SynplifyPro. > >Article: 119941
Kolja wrote: > But the original 6502 is to old to have still open patent issues. Not in the US. "Submarine patents" can be issued many years after the invention was actually made. For instance, the Gilbert Hyatt patent, US 4,942,516, on the microprocessor, based on an original filing in 1970 but granted in 1990. There are other cases where patents issued more than 60 years after application. TI got a court to invalidate some but not all of the claims of that patent. I think it is safe to say that it is *unlikely* for any patent issues to arise based on a new straightforward implementation of the 6502 ISA, but it's not impossible. Submarine US patents are somewhat less likely to be a problem in the future due to the recent changes to US patent law. Eric References: http://en.wikipedia.org/wiki/Submarine_patent http://www.marketsandpatents.com/wp_01.htmlArticle: 119942
koustav79@gmail.com writes: > I am primarily interested in > s/w interfaces for accesing DDR memory like reading and writing data > at a particular address Unless I misunderstand the question: #include <stdint.h> uint32_t addr = 0x00001234; // some address you want to access uint8_t *ptr = (uint8_t *) addr; foo = *ptr; // read a byte at ptr *ptr = 0xaa; // write a byte 0xaa at ptr > and also writing on-board LEDs and reading DIP > switches. Same as above, but put a "volatile" in the pointer declaration: volatile uint8_t *switches_ptr = (uint8_t *) 0x02000000; volatile uint8_t *leds_ptr = (uint8_t *) 0x03000000; uint8_t switches = *switches_ptr; *leds_ptr = 0x55; Of course, you have to change the addresses to match your system.Article: 119943
"John Williams" <jwilliams@itee.uq.edu.au> wrote in message news:465CA95F.9030905@itee.uq.edu.au... > Hi Dave, > > Dave wrote: > > > I bought an SZ010 board for use in a PVR project, thinking the EDK/Linux > > design would provide a fast development route. In the end this proved > > impractical, simply because uCLinux running on a Microblaze (which maxes out > > at about 52MHz in this case) doesn't provide good enough network > > performance - from memory, an ftp test was clocking in at around 3 mbits/s. > > The Suzaku's interface to the off-chip MAC-PHY has no DMA capability, > which goes a long way to explaining the poor ethernet throughput you > describe. With the Xilinx EMAC, and DMA, checksum offload and all bells > and whistles we've hit 50mbit/sec with MicroBlaze / uClinux systems in > netperf tests. > > Just to put the record straight... > Yes, my reply was overly simplistic and skipped over the middle ground for no reason other than it being what I did. The main point for the OP is that the Suzaku requires more effort than just bolting in application-specific extras. Having not used the EDK before and really not requiring Linux for anything other than pinching the network stack, I personally found it easier to start from scratch. Cheers, DaveArticle: 119944
John_H wrote: > > An IFFT is just an FFT of an FFT, perhaps scaled by a factor of 2*pi (or > other constant scaling) depending on the Fourier Transform scaling used > for the FFT. > Not exactly. The rotations are in the opposite directions. You can perform an IFFT with an FFT by performing a complex conjugate operation on the inputs and on the outputs of the FFT: f(t) = FFT(F(s)*)* where f(t) is the inverse transform of F(s) and * denotes complex conjugate. There is also the issue of scaling by N where N is the number of points in the FFT. The scaling depends on the FFT definition used however. If you have access to the guts of the FFT, you can also convert it to an inverse FFT by reversing the twiddle rotations, which is done by doing the complex conjugate on the complex twiddles.Article: 119945
Austin, So those VREF pins can still be used as user I/O pins if I use GTL output? If so that will be great. I tried using one GTL output and the constraint editor assigned the output as GTLP and the I/O Pin corresponding to VREF was assigned as VREF PIN. This is why I am asking. THanks.Article: 119946
Hi,
I'm working on implementing an FIR Filter on a FPGA (Spartan 3E),
here's what i want to accomplish -->
The FIR Filter coefficients are generated on a host system using
LabView, these coefficients are written to a RAM / PROM on a DSP
card , the number of taps is constant but other parameters like
sampling frequency and cut off frequencies can change according to
requirements.
The FPGA reads these coefficients from the RAM / PROM and implements
the FIR Filter.There should be a single bit file that is downloaded to
configure the FPGA.
Any pointers in the right direction would be appreciated.
Thanks
Tim
Article: 119947Peter wrote: > > I am convinced that the problem is in all Virtex and Spartan devices > Aaaaack! Even in pre-Virtex-2 BRAMS? > > And I also do not see any fix that would maintain BRAM access time. > Ideally, the write enable line would actually disable writes when it is deasserted. Lacking that, the next best thing (for safer Block ROMs) would be a "write protect" attribute (per port, or per BRAM) in the BRAM configuration, that disables the writes completely. Perhaps the necessary configuration bits already lurk unused in the bitstream, waiting only for a patch to set them free... > > And it takes a peculiar set of non-deterministic circumstances > to result in an error. > Unfortunately, those circumstances as close as your next DCM startup. Certain simple DCM configurations could use bitgen's wait-for-DCM- lock startup option as a workaround ( but that has its' own problems ) > > But I did not think about the DCM losing lock :-( > Any loss/glitch of your clock will do, DCM or no DCM; after which a reset alone is not sufficient to recover, the Block ROM must be reloaded. A hypothetical example: As you're testing the latest whiz-bang SDR block in the lab, every time you change the rate of the sample clock the #$%^%@! FPGA needs to be re-downloaded, rather than merely reset, because the DSP cores don't bring out the Block ROM enable lines needed to protect their internal coefficient ROMs while the clock synthesizer is retuned. BrianArticle: 119948
Brian, there is a perfect cure: disable the clock. The problem can only occur when the clock is enabled. Peter On May 29, 7:34 pm, Brian Davis <brimda...@aol.com> wrote: > Peter wrote: > > > I am convinced that the problem is in all Virtex and Spartan devices > > Aaaaack! Even in pre-Virtex-2 BRAMS? > > > > > And I also do not see any fix that would maintain BRAM access time. > > Ideally, the write enable line would actually disable writes > when it is deasserted. > > Lacking that, the next best thing (for safer Block ROMs) would be > a "write protect" attribute (per port, or per BRAM) in the BRAM > configuration, that disables the writes completely. > > Perhaps the necessary configuration bits already lurk unused > in the bitstream, waiting only for a patch to set them free... > > > > > And it takes a peculiar set of non-deterministic circumstances > > to result in an error. > > Unfortunately, those circumstances as close as your next DCM startup. > > Certain simple DCM configurations could use bitgen's wait-for-DCM- > lock > startup option as a workaround ( but that has its' own problems ) > > > > > But I did not think about the DCM losing lock :-( > > Any loss/glitch of your clock will do, DCM or no DCM; after which > a reset alone is not sufficient to recover, the Block ROM must be > reloaded. > > A hypothetical example: > > As you're testing the latest whiz-bang SDR block in the lab, > every time you change the rate of the sample clock the #$%^%@! FPGA > needs to be re-downloaded, rather than merely reset, because the DSP > cores don't bring out the Block ROM enable lines needed to protect > their internal coefficient ROMs while the clock synthesizer is > retuned. > > BrianArticle: 119949
>> I'm working with a board MPC8548CDS-like (PowerPC). Connected to >> processor local bus and with pci express there is a Virtex 4 >> (xc4vfx60). >Hopefully the board vendor has also provided a PCI-express interface >core for the FPGA. You will need to customise / use this core, define >the PCI BAR (base address register) functionality, and then write a >standard linux driver to talk to the FPGA as though it were any PCI / >PCI-e device. if your FPGA appears as a PCI device with PCI memory (instead of I/O space) you can just mmap it from /dev/mem. You need super-user priveleges to do that, but it means that the driver can run in user space. Use scanpci to locate your device and setpci to read its PCI config -- mac the naïf
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