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
vcar wrote: > For certainreasons, I could not use battery on my board, so the > Virtex5 bitstream encryptioncould not be used. In this situation, what > could I do to protect my design on areasonable level? I don't know the answers to your questions, but I guess an attacker could at least just desolder the XCF16P and reading it like the FPGA does when booting, so even the read protection bit of the flash is useless. If you want to secure your device, I would use something like the DS2401. This provides a unique id. You could save this in the flash and compare it from the FPGA with the chip. The chip is available in packages which looks like a capacitor or diode: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=DS2401X1CT-ND I've written some VHDL code for reading the one-wire id: http://www.frank-buss.de/vhdl/spartan3e.html (see the DS2432 ROM id reader in the zip file) -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 144726
Am 29.12.2009 08:27, schrieb John Butler: > The STATE is getting assigned in separate sequential process. Write to a signal/variable only in one always statement! Although Verilog allows the other way, it is a bad coding style and error-prone. > Also do I need to put all the signals being checked in the always > block ( e.g counter and count_down_cnt etc). > > always @(STATE or counter) > begin: FSM_COMBO1_I > > case(STATE) ... If you do it this way: then yes. You have written a pure combinational always statement. For this this is necessary to have all signals in the sensitivity list. But you could merge the combinational always statement that results in the next_STATE signal with the synchronous always statement, that assigns next_STATE to STATE. Then you only have one synchronous always statement and for this only the clock (and an asynchronous reset) needs to be put in the sensitivity list. RalfArticle: 144727
On Mon, 28 Dec 2009 23:27:05 -0800 (PST), John Butler <john.butler121@gmail.com> wrote: >I have this code which seems to run OK in RTL and gatelevel >simulation but I m getting glitches in signaltap and in oscilloscope. > You don't define which signals are showing glitches. Are you seeing glitches in STATE or some other signals? >Also do I need to put all the signals being checked in the always >block ( e.g counter and count_down_cnt etc). > For simulation/synthesis matching usually yes. For synthesis only, the tool already assumes it so sometimes there can be mismatches so it's safer to do that. Are you registering rdreq, rdreq1, output1, counter_cnt_en etc. signals ala STATE? If they're not registered and as you don't assign them at the top of FSM_COMBO1_I block, you will get latches for them and these latches may cause the problems you're observing. Also what is next_STATE1_I signal used for? It seems like a typo. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 144728
Frank Buss <fb@frank-buss.de> wrote: > vcar wrote: >> For certainreasons, I could not use battery on my board, so the >> Virtex5 bitstream encryptioncould not be used. In this situation, what >> could I do to protect my design on areasonable level? Protecting against exact clones is difficult. In many cases, decoding the bits back to logic is hard enough not to worry about that. > I don't know the answers to your questions, but I guess an attacker could > at least just desolder the XCF16P and reading it like the FPGA does when > booting, so even the read protection bit of the flash is useless. If you > want to secure your device, I would use something like the DS2401. This > provides a unique id. You could save this in the flash and compare it from > the FPGA with the chip. The chip is available in packages which looks like > a capacitor or diode: As long as they don't read this newsgroup and know what to look for... -- glenArticle: 144729
glen herrmannsfeldt wrote: > As long as they don't read this newsgroup and know what to look for... You are right. And if an attacker has the money to clone a Virtex design, this just delays the cloning process a bit. But the AES encryption integrated in Virtex devices is better. It's a pity that the key can't be stored in non-volatile memory inside the chip. Another idea against cloning would be to implement a challenge response protocol with an external small microcontroller, e.g. a hash function, where the microcontroller adds some bytes before hashing. If the microcontroller has some protection, then the attacker would need at least an electron microscope (assuming that it is not easy to extract the logic from the programming byte stream for the Virtex). -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 144730
On 28 dez, 04:17, Amal <akhailt...@gmail.com> wrote: > On Dec 26, 3:14=A0pm, Muzaffer Kal <k...@dspia.com> wrote: > > > > > On Fri, 25 Dec 2009 21:38:48 -0700, Rob Doyle <radioe...@gmail.com> > > wrote: > > > >If I *had* to add another write port to the memory - can you do that > > >using memories? =A0I can't see it... > > > One thing you can do is to =A0have two copies of your register file and > > keep a 'most-recently-written' state for each location. Then each read > > path =A0has an additional 2-1 mux after it controlled by the same signa= l > > (and a comparator for the read address). This should give the datapath > > you want but whether the extra delay is acceptable depends on your > > requirements. > > -- > > Muzaffer Kal > > > DSPIA INC. > > ASIC/FPGA Design Services > > >http://www.dspia.com > > Xilinx supports 3-port memories as well if it helps. =A0You can have one > read/write port and two read ports with 3 different addresses. > > You can either infer it or instantiate the component directly. > > Cheers, > -- Amal Amal, Are native 3-port mode supported by which Xilinx devices? Without duplicating memories? Is there any constraint about using this operation mode combined with different aspect data ratio? I had heard something about native support of 3-port (two read and one write port with 3 different addresses) in Altera devices only. SelenskyArticle: 144731
Hello world, I'm looking at making my first FPGA board with a Cyclone III EP3C25 and am researching my boot memory solution. Reading Altera's docs they reference their EPCS series serial programming chips but they run for an outlandish $16 - $32 on Newark. Googling got me to this page: http://fpgaforum.blogspot.com/2006/03/any-replacement-for-altera-epcs_19.html that claims that their so called EPCS programming chips are nothing more than SPI flash. Can anyone confirm this? I am looking at getting the SST25VF032B 32Mb (4M x 8) SPI Flash memory. Thanks, Omer OsmanArticle: 144732
On Dec 29, 12:36=A0pm, Omer Osman <resea...@ottomaneng.com> wrote: > Hello world, > > I'm looking at making my first FPGA board with a Cyclone III EP3C25 > and am researching my boot memory solution. Reading Altera's docs they > reference their EPCS series serial programming chips but they run for > an outlandish $16 - $32 on Newark. > > Googling got me to this page:http://fpgaforum.blogspot.com/2006/03/any-re= placement-for-altera-epcs... > that claims that their so called EPCS programming chips are nothing > more than SPI flash. Can anyone confirm this? I am looking at getting > the SST25VF032B 32Mb (4M x 8) SPI Flash memory. > > Thanks, > > Omer Osman This is true. I use M25P16's on my Cyclone III boards, and they boot just fine. I normally use in-system programming via JTAG, but they should be programmable with active serial as well.Article: 144733
rickman wrote: > On Dec 28, 3:40 am, whygee <y...@yg.yg> wrote: >> hello, >> >> Amal wrote: >>> Xilinx supports 3-port memories as well if it helps. You can have one >>> read/write port and two read ports with 3 different addresses. >>> You can either infer it or instantiate the component directly. >> the OP and the thread are speaking about multiple write port, >> because multiple read ports are trivially implemented. >> However, simultaneously having 2 read AND 2 write ports >> (4 simultaneous addresses, for example) is not as easy >> and I guess that few synthesisers will infer the correct >> SRAM blocks. > > The OP doesn't need four ports from a single memory, only three are > needed. If two write ports are needed, there is no way to fake that, > at least no easy way. Three ports are needed, two write and one > read. Then as many read ports can be added as needed by duplicating > the memory with separate read addresses. If the OP can use the same > address for one write port and the read port, then this is just a two > port memory with read/write capability. > > If a two write, one read port memory with three addresses is needed > and only two addresses can be input to the memory, then a third memory > can be used to "arbitrate" between two duplicated, two address, one > write, one read port memories. When a write happens, the data is > written to the memory connected to that write port. The third memory > is just one bit wide and the bit at the corresponding address is set > or reset to indicate which port the most recent write has been from. > When a read is done, a mux selects from the appropriate memory block. > The only fly in the ointment is that the "flag" memory has to have two > write and two read ports. So it can't be done in a block ram, but > must be made of logic and FFs. That is some savings over doing the > entire memory in logic if it is wider than one bit... but still a PITA > and quite a mess. But if you *have* to have this memory and the part > does not support it... I guess you have no choice, eh? > > Rick I *need* one write port and three read ports - so I'm OK just duplicating the RAM. I could save a clock cycle in the ALU if I could do two writes and three reads. If I have to stall the pipeline to implement this, I've gained nothing. The timing won't permit 2 Register clock cycles per ALU clock cycle to double-up the register accesses. The multi-port "flag" memory is the trick I was looking for. The ALU has 1024 registers so I can envision some tall data selectors, multiplexers, and accompanying levels of logic to implement the address decoders. I think I'm going to stay with simple for now and put this in my back pocket as "Plan B". I greatly appreciate the help. Rob DoyleArticle: 144734
I looked at the postmark on my Atmel Synplicity CD and it was December 2000. I figure the chances of retrieving my serial number are nil and I'll assume most people would advise me to get something a little more up to date. It really has been about a 9 year FPGA hiatus for me as the company I was helping at the time tanked. I want to get back into some 'trivial' design work. I'm thinking my level of sophistication is still at the ~22v10 stage and using schematic capture vs. programming languages or assembler. I have read enough to know this is bad form but I still understand 74LSXX and would like to ease into topics like Verilog. Nothing I do requires more then a couple of 4 bit counters and maybe a six bit latch with a bit of glue logic. It goes without saying I'm a fan of inexpensive as well as dated. I've seen several web sites with low cost entry level kits and programmers that will handle 22V10s for under $100. Can someone tell me what is a good start for someone with my particular needs? Info like: Best software does not work with xxx so get a programmer that works with yyy. TIA RickArticle: 144735
Rick wrote: > I want to get back into some 'trivial' design work. I'm thinking my > level of sophistication is still at the ~22v10 stage and using > schematic capture vs. programming languages or assembler. I have read > enough to know this is bad form but I still understand 74LSXX and > would like to ease into topics like Verilog. Nothing I do requires > more then a couple of 4 bit counters and maybe a six bit latch with a > bit of glue logic. You can do such small logic with a small CPLD, e.g. the XC9572XL from Xilinx (I've managed to implement two 19 bit counters with it and a SPI interface for reading). Just download the free Web Edition of Xilinx ISE and then you can write Verilog or VHDL designs and test it in the integrated simulator. If you want a starter kit, maybe this one is a good idea: http://www.xilinx.com/products/devkits/DO-CPLD-DK-G.htm If you want to program it in your own boards later, I can recommend the Xilinx Platform Cable. Altera has a free web edition of the development environment, too and some nice CPLDs and starter kits, and some Lattice CPLDs are really inexpensive, but I don't know the development tools. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 144736
On Tue, 29 Dec 2009 14:37:18 -0700, Rob Doyle <radioengr@gmail.com> wrote: >rickman wrote: >> On Dec 28, 3:40 am, whygee <y...@yg.yg> wrote: >>> hello, >>> >>> Amal wrote: >>>> Xilinx supports 3-port memories as well if it helps. You can have one >>>> read/write port and two read ports with 3 different addresses. >I could save a clock cycle in the ALU if I could do two writes >and three reads. If I have to stall the pipeline to implement >this, I've gained nothing. > >The timing won't permit 2 Register clock cycles per ALU clock cycle >to double-up the register accesses. > >The multi-port "flag" memory is the trick I was looking for. The ALU >has 1024 registers so I can envision some tall data selectors, >multiplexers, and accompanying levels of logic to implement the >address decoders. Another trick, IF you have some control over the instruction set, is to split the register set in two. Then you can schedule two writes, provided they are to different halves. (The read side can appear as a single unified regset) With the large number of registers a BRAM gives you, it is likely that there will always be "vacant" slots in each half. So this restriction can usually be hidden by register allocation policy, if you get to dictate such restrictions to whoever is writing the code generator. Essentially you trade simpler hardware for some additional complexity in software; the compiler writers make that invisible to the user. - BrianArticle: 144737
Rick <richardcortese@gmail.com> writes: >I looked at the postmark on my Atmel Synplicity CD and it was December >2000. I figure the chances of retrieving my serial number are nil and >I'll assume most people would advise me to get something a little >more up to date. It really has been about a 9 year FPGA hiatus for me >as the company I was helping at the time tanked. >I want to get back into some 'trivial' design work. I'm thinking my >level of sophistication is still at the ~22v10 stage and using >schematic capture vs. programming languages or assembler. I have read >enough to know this is bad form but I still understand 74LSXX and >would like to ease into topics like Verilog. Nothing I do requires >more then a couple of 4 bit counters and maybe a six bit latch with a >bit of glue logic. >It goes without saying I'm a fan of inexpensive as well as dated. I've >seen several web sites with low cost entry level kits and programmers >that will handle 22V10s for under $100. >Can someone tell me what is a good start for someone with my >particular needs? Info like: Best software does not work with xxx so >get a programmer that works with yyy. >TIA >Rick Since I was just down a similar route (although in the end I managed to find a compiled file of the 16V8 and 20V8 I needed and ran it through my B+K prom programmer without having to compile the palasm source), you likely want to look at Lattice. They bought MMI and the older versions of their software are still available for free on their web site and appear to support the various PALs probably including schematic capture (I needed palasm). I think pretty much any programmer that supports the various PALS will do. As well as the B+K I have a PC ISA board from the 1980s that will do the various pals and gals although I haven't used it in years just check the programmer supports the PALs you want to use Altera's QuartisII (at least a couple of years ago) supported schematic capture/generation of images (as well as Verilog or VHDL) in the free web edition. I haven't used it recently nor ISE from Xilinx enough to know it they still do. However neiher as far as I know support PALs only their CPLDs and the CPLDs are (again as far as I know) all in PLCC packages, not PDIP like the pals. As well some of the pals are available (cheap!) from the surplus houses such as All or B+G Micro (ping me if you need web sites) thats where I got the blanks for the pair I needed :-). Peter Van EppArticle: 144738
On 12=D4=C229=C8=D5, =CF=C2=CE=E76=CA=B112=B7=D6, glen herrmannsfeldt <g...= @ugcs.caltech.edu> wrote: > Frank Buss <f...@frank-buss.de> wrote: > > vcar wrote: > >> For certainreasons, I could not use battery on my board, so the > >> Virtex5 bitstream encryptioncould not be used. In this situation, what > >> could I do to protect my design on areasonable level? > > Protecting against exact clones is difficult. In many cases, decoding > the bits back to logic is hard enough not to worry about that. > > > I don't know the answers to your questions, but I guess an attacker cou= ld > > at least just desolder the XCF16P and reading it like the FPGA does whe= n > > booting, so even the read protection bit of the flash is useless. If yo= u > > want to secure your device, I would use something like the DS2401. This > > provides a unique id. You could save this in the flash and compare it f= rom > > the FPGA with the chip. The chip is available in packages which looks l= ike > > a capacitor or diode: > > As long as they don't read this newsgroup and know what to look for... > > -- glen Hi, glen. My point is to protect my board from cloning, so the attacker do not need to decoding bit stream back to logic. Once they obtain the bit stream, they can produce my board themselves. I could not protect the PCB from cloning, so I have to do something on my bit stream. Otherwise it is very easy to copy my board.Article: 144739
On Dec 29, 4:44=A0pm, van...@sfu.ca (Peter Van Epp) wrote: > Rick <richardcort...@gmail.com> writes: <snip> > =A0 =A0 =A0 =A0 Since I was just down a similar route (although in the en= d I managed > to find a compiled file of the 16V8 and 20V8 I needed and ran it through = my > B+K prom programmer without having to compile the palasm source), you lik= ely > want to look at Lattice. They bought MMI and the older versions of their > software are still available for free =A0on their web site and appear to > support the various PALs probably including schematic capture (I needed p= alasm). > =A0 =A0 =A0 =A0 I think pretty much any programmer that supports the vari= ous PALS will > do. As well as the B+K I have a PC ISA board from the 1980s that will do = the > various pals and gals although I haven't used it in years just check the > programmer supports the PALs you want to use Hehe! I was looking for software for my Needham PB-10 earlier. I actually found some that is supposed to run under XP but I have to put it in a computer with ISA slots. I should give up the ghost. I went ahead and got the development board from Frank's link. It was only $39+ shipping so it will get me into the current decade. Checked with Digikey and they have the CPLD in 44 pin PLCC so at least I can buy a carrier for wire wrap. Price is right too at about $2 per chip. I will give the Lattice a look and see what I can find. I am trying to tell myself I am better off with a 44 pin CPLD then a 28 pin GAL. The CPLD still seems like a lot of club for the distance but prices are about even. RickArticle: 144740
On 12=D4=C229=C8=D5, =CF=C2=CE=E74=CA=B129=B7=D6, Frank Buss <f...@frank-bu= ss.de> wrote: > vcar wrote: > > For certainreasons, I could not use battery on my board, so the > > Virtex5 bitstream encryptioncould not be used. In this situation, what > > could I do to protect my design on areasonable level? > > I don't know the answers to your questions, but I guess an attacker could > at least just desolder the XCF16P and reading it like the FPGA does when > booting, so even the read protection bit of the flash is useless. If you > want to secure your device, I would use something like the DS2401. This > provides a unique id. You could save this in the flash and compare it fro= m > the FPGA with the chip. The chip is available in packages which looks lik= e > a capacitor or diode: > > http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=3DDS24..= . > > I've written some VHDL code for reading the one-wire id: > > http://www.frank-buss.de/vhdl/spartan3e.html > > (see the DS2432 ROM id reader in the zip file) > > -- > Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys= tems.de Comparing to DS2401, DS28E01 or DS2432 is more applicable. If I use these chips, need I use BSCAN_VIRTEX5 + ICAP_VIRTEX5 to monitor JTAG activities?Article: 144741
vcar <hitsx@163.com> wrote: >On 12=D4=C229=C8=D5, =CF=C2=CE=E76=CA=B112=B7=D6, glen herrmannsfeldt <g...= >@ugcs.caltech.edu> wrote: >> Frank Buss <f...@frank-buss.de> wrote: >> > vcar wrote: >> >> For certainreasons, I could not use battery on my board, so the >> >> Virtex5 bitstream encryptioncould not be used. In this situation, what >> >> could I do to protect my design on areasonable level? >> >> Protecting against exact clones is difficult. In many cases, decoding >> the bits back to logic is hard enough not to worry about that. >> >> > I don't know the answers to your questions, but I guess an attacker cou= >ld >> > at least just desolder the XCF16P and reading it like the FPGA does whe= >n >> > booting, so even the read protection bit of the flash is useless. If yo= >u >> > want to secure your device, I would use something like the DS2401. This >> > provides a unique id. You could save this in the flash and compare it f= >rom >> > the FPGA with the chip. The chip is available in packages which looks l= >ike >> > a capacitor or diode: >> >> As long as they don't read this newsgroup and know what to look for... >> >> -- glen > >Hi, glen. >My point is to protect my board from cloning, so the attacker do not >need to decoding bit stream back to logic. Once they obtain the bit >stream, they can produce my board themselves. >I could not protect the PCB from cloning, so I have to do something on >my bit stream. Otherwise it is very easy to copy my board. In that case you'll need to add a microcontroller which does part of the job. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 144742
vcar wrote: > Comparing to DS2401, DS28E01 or DS2432 is more applicable. You are right, the DS2432 looks interesting with the SHA1 hash function. But I couldn't find it at Digikey and you have to register at Maxim to just get the price for it, so maybe a small PIC (which has program read protection) is better. > If I use these chips, need I use BSCAN_VIRTEX5 + ICAP_VIRTEX5 to > monitor JTAG activities? I don't think this is needed, because an attacker could desolder the flash anyway and simulate a FPGA to read the bitstream, or use a logic analyzer for recording the FPGA boot process. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 144743
i have a cypress fx2lp usb2 that emulates an ACE hdl player and outputs the
Jtag directly to an XCF32P and an SX55.
there are a couple of issues i am still not sure about though,
1- on a TDO check, the ace file gives me the output data for TDI, a mask,
and an expected return value.
The SX55 and XCF32P have a combined TDO buffer of 26 bits, so from what
i gather i dont get the data back out for 26 clock cycles, does this mean
that i should just continue clocking with no new instructions or data until
i get all the data back or do i continue feeding in new instructions and
just wait the 26 clocks like that?
2- what is the maximum TDO length for an ACE file? i have the FX2LP packed
full and can barely fit in another byte of storage, if i have to hold 100+
bytes in ram to check later im kind of screwed...
3- the XAPP424 talks about having to clock on the runtest instruction if it
is configuring an FPGA, the FX2LP link is not exactly fast enough to
continuously feed data through so the clock is sometimes just held high or
low for slightly longer periods on different instructions as im just
bit-banging it. should i slow it all down so i have a continuous clock
period or does it not matter as only the rising edge and minimum clock high
periods are the only important parts?
Article: 144744On Dec 25, 4:53=A0pm, wzab <w...@wzab.nasz.dom> wrote: > To simplify design of the DSP system I have decided to describe the > ports connecting different blocks (to be synthesized in the same FPGA) as= a > record. > It resulted in a code, in which two different processes (each in one of > connected blocks) assign values to the different fields of the same recor= d. > Unfortunately my VHDL simulator (namely: GHDL) recognizes this situation > as the conflict, and sets the whole record to 'U'. > What exactly is connected to the ports? The entire record or the particular element of the record? If it's the entire record, like this... u1 : entity work.my_thing1 port map(s =3D> my_record); u2 : entity work.my_thing2 port map(v =3D> my_record); Then you will have problems because (as you've begun to discover based on your later post) you will have multiple processes driving the 'my_record' signal. It doesn't matter that the entity only has one obvious statement that is driving one element of the record. > Have I really overlooked something in the VHDL rules? The fact is that the two entities are defined to have an output that is of the record type. That you choose to not have anything in the architecture for that entity to drive the other elements of the record means that those other elements gets the VHDL default assignment of 'U'. > It seems, that it should not be considered a conflict, as each field is d= riven > by a single process. The output of the entity in your case is not an element of the record, but the record itself. Kevin JenningsArticle: 144745
On Dec 26, 3:28=A0am, Eric Smith <space...@gmail.com> wrote: > As enticing as it is, I've found that using record types in > synthesizable VHDL is just inviting problems. =A0 Not using records, just invites other problems...like when bit fields definitions change. A record allows this change to be handled completely in one file, three locations in that file: in the record definition and within two functions. Not using a record involves finding and changing every instance where the (could've been) record is used, which is generally in far more places in the code and not always as easy to find. Plus to find them, you need to rely on text search tools rather than the VHDL compiler. Far more likely to miss an usage instance in that case, thus the problem Kevin JenningsArticle: 144746
On 12/29/2009 6:38 PM, Frank Buss wrote: > Rick wrote: > >> I want to get back into some 'trivial' design work. I'm thinking my >> level of sophistication is still at the ~22v10 stage and using >> schematic capture vs. programming languages or assembler. I have read >> enough to know this is bad form but I still understand 74LSXX and >> would like to ease into topics like Verilog. Nothing I do requires >> more then a couple of 4 bit counters and maybe a six bit latch with a >> bit of glue logic. > > You can do such small logic with a small CPLD, e.g. the XC9572XL from > Xilinx (I've managed to implement two 19 bit counters with it and a SPI > interface for reading). Just download the free Web Edition of Xilinx ISE > and then you can write Verilog or VHDL designs and test it in the > integrated simulator. > > If you want a starter kit, maybe this one is a good idea: > > http://www.xilinx.com/products/devkits/DO-CPLD-DK-G.htm > > If you want to program it in your own boards later, I can recommend the > Xilinx Platform Cable. > > Altera has a free web edition of the development environment, too and some > nice CPLDs and starter kits, and some Lattice CPLDs are really inexpensive, > but I don't know the development tools. > Looks like the programming cable included in that kit is for a parallel port. Few recent PCs have parallel ports anymore, and I understand that USB-to-parallel converters generally don't work with JTAG cables (or more accurately with the software). And while the Xilinx platform cable is a great solution, its costs over $200. For playing around at home I've had good luck with stuff from Digilent: www.digilentinc.com (in fact they made the board in your kit). They have USB JTAG cable that's compatible with Xilinx tools and only costs $60. They also have two types of USB JTAG cable that work with their free programming software (called Adept) and are even less expensive. These are all on the "Cables & connectors" page. For playing with very simple logic Digilent also has a small board with a CoolRunner CPLD for $18 (look for "C-Mod"). It's basically just a way to mount the PLCC and bring the connections to DIP pads for easy experimenter access, but sometimes that's really handy. Of course the C-Mod is only 64 macrocells. Digilent also has fairly inexpensive FPGA experimenter boards: the "Basys2" board has a Spartan 3E with 100k gates for $80, and the "Nexys" board has a Spartan 3 with 400k gates for $90. Those boards have USB built in, and don't even require an additional programming cable. ChrisArticle: 144747
On Dec 25, 5:50=A0pm, wzab <w...@ise.pw.edu.pl> wrote: > I have found the following discussion:http://www.velocityreviews.com/foru= ms/t487026-vhdl-port-inout-problem... > > And according to the solution decribed there, I set ALL fields (elements)= =A0 > of the record in ALL processes. If the particular process does not drive > the particular signal, I set it to "Z". > Step back a minute and think about why you would have an entity that is defined to have a record output that does not drive all the elements? Doesn't that seem to you like the entity *really* does not have the record output that you've defined? (Hint: The answer is 'yes'). What this suggests is that you've defined the record per some pre- conceived notion of how it should be, but it does not match how you're defining your entities. You should go back to the drawing board and re-think the record definitions to match how you really intend to use them. The alternative is the kludge you've found regarding setting unused record fields to 'Z'. Kevin JenningsArticle: 144748
I realized i was reading the TDO instructions incorrectly from the XAPP424 and so i only need to store 26 bits or mask and 26 of expected TDO and 26 bits of received TDO, i thought it was <opcode><all TDI data><all TDO expected><all TDO mask>, but it looks like it is broken into bytes of each... <0x04><numbits> <TDI byte> <TDO exp byte> <TDO mask byte> <TDI byte> <TDO exp> ... unfortunately it takes about an hour to run this programming procedure as the ace file is about 40MB which has to go down endpoint0 and i have an error check so its 2 transfers for every 32bytes. i will update if it worked... --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 144749
Rick <richardcortese@gmail.com> writes: >On Dec 29, 4:44=A0pm, van...@sfu.ca (Peter Van Epp) wrote: >> Rick <richardcort...@gmail.com> writes: ><snip> >Hehe! I was looking for software for my Needham PB-10 earlier. I >actually found some that is supposed to run under XP but I have to put >it in a computer with ISA slots. I should give up the ghost. I still have the XT clone that it originally ran in (and several other ISA machines :-)). I even still have an operating Z80 CPM machine (and am building a nwe one :-)). >I went ahead and got the development board from Frank's link. It was >only $39+ shipping so it will get me into the current decade. Checked >with Digikey and they have the CPLD in 44 pin PLCC so at least I can >buy a carrier for wire wrap. Price is right too at about $2 per chip. Horrors! Not an adapter ($$$$), a through hole PLCC socket and some sip www sockets from Jameco (6100-1X30W-R) or Electronix Express (ssw30s) (http://www.elexp.com/ics_sf10.htm and cheapest), All had some at $.50 some months back but I cleaned them out :-). Cut to suitable lengths for the PLCC pins the through hole plcc socket plugs in on .1 centers giving you a wirewrap adapter for a couple of bucks (you may have to experiment with PLCC sockets if the pins are too big, all those I've tried have worked though). This is how my 84 PLCC Z80 chip is wire wrapped in. >I will give the Lattice a look and see what I can find. I am trying to >tell myself I am better off with a 44 pin CPLD then a 28 pin GAL. The >CPLD still seems like a lot of club for the distance but prices are >about even. True, and learning the new stuff is a good thing for sure but if a PAL will do the job, by the time you add in socket cost and board area the PALs may still be a better bet against a PLCC device (not to mention a lot of the CPLDs are going 3.3V only). Sometimes the old stuff is still best. Peter Van Epp
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