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
cblsrv emulates a Par III cable, so Impact doesn't have any idea, cblsrv would use a Platform USB cable. One working firmware would be good enough (unless they change the cableserver protocoll when using Par III) The windows debugging part is fairly easy, no breakpoints, or anything nasty, just simply put API trace logs with dumping incoming/outgoing data. I'd be more interested to reverse engineer the Platform USB than Par IV, because most new laptops and some desktops lack par ports anyway. Reverse engineer the Digilent USB JTAG cable took roughly 2 days to reverse engineer the basic protocol, but maybe the Platform USB is much nastier. Zoltan Antti wrote: > zcsizmadia@gmail.com schrieb: > > > Probably I miss something here. > > > > Why not just hook LPT or Jungo driver in windows, and see what is sent > > to the cable? Or it is downloading the firmware at the very beginning > > and it's a copyright issue to include the original firmware in your > > open-source application? > > The same way using a USB sniffer the communication can be reverse > > engineered (unless the data is not crypted) > > > > Do you have any Par IV or Platform USB cable I could borrow to see if > > it could be reverse engineered? > > > > Zoltan > > > Zoltan, > > snooping the USB cable does not make much sense as it is always > downloading the actual firmware, those any new release of ISE may have > different firmware and completly new USB protocol. It could of course > be possible to write an emulator for the USB chip and use the actual > firmware, by emulating it in fake driver, but that is all too > time consuming. > > now as of Cable IV, well I havent done windows kernel debugging for > ages. I used todo it. But as of today I dont have debug tools that can > put breakpoints on io access in running winXP system. Sure it can be > done when windows is installed in qemu, etc, but its all > pretty much pain. > > Or another way is to reverse engineer some xilinx DLL, what defenetly > violates the licensing, and is boring anyway. > > So third option is to look at the jedec readback from Cable IV, sure > after conversion to VHDL. > > AnttiArticle: 108201
zcsizmadia@gmail.com schrieb: > cblsrv emulates a Par III cable, so Impact doesn't have any idea, > cblsrv would use a Platform USB cable. One working firmware would be > good enough (unless they change the cableserver protocoll when using > Par III) > > The windows debugging part is fairly easy, no breakpoints, or anything > nasty, just simply put API trace logs with dumping incoming/outgoing > data. > > I'd be more interested to reverse engineer the Platform USB than Par > IV, because most new laptops and some desktops lack par ports anyway. > > Reverse engineer the Digilent USB JTAG cable took roughly 2 days to > reverse engineer the basic protocol, but maybe the Platform USB is much > nastier. > > Zoltan > ah? I am gettin old or what? you can put "API trace logs" read write to physical IO? to reverse the Cable IV that is required. as of platform USB cable, it makes sens to use the natice cableserver as gateway, so you are not troubled with the USB protocol or firmware revision, etc AnttiArticle: 108202
Uwe, Did you have a chance to try my patch? > Well, you probably don't need PPEXCL. The man page says: I had the impression if you write CONTROL you need it. DLC5 doesn't writes CONTROL, but Altera ByteBlaster does. In my vmware environment I removed PPEXCL and it works for me (of course with the patch) > ioctl(...) !=0 I've already fixed them. Next week probably I'll finish the Digilent USB JTAG cable support in cblsrv, and will make a new release with the patches. Zoltan Uwe Bonnes wrote: > zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote: > > On Linux the only test I did was using VmWare with direct I/O access > > (actually ppdev didn't work for me, it said PPEXCL failed). > > Well, you probably don't need PPEXCL. The man page says: > > "Most device drivers don't need exclusive access to the port. It's only > provided in case it is really needed, for example for devices where access > to the port is required for extensive periods of time (many seconds)." > > And testing for failure for an ioctl is better done like > ioctl(...) !=0 > > > Did you try to use with DIRECT_IO? > > Running cblsrv as root (and having windrvr6 still loaded) worked. However > after unloading the windrvr6 module, I couldn't get things to work. > > > There is a cablehost directory under src. You can patch that to connect > > to server and send some messages. I've used it to connet tit to the > > Xilinx CableServer and figure out what the different write modes meant > > cablehost is for win32... > > > PS: > > This weeken I'll try to more Linux testing. > > Fine > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 108203
Mike Treseler wrote: > Weng Tianxiang wrote: > > > I even deleted all work directory contents, recompile every modules, > > but constants in the global package still don't change. > > Maybe they are declared in more than one place. > > -- Mike Treseler Hi MIke, Never! I tried to move all constant definitions from package entity module to package body module, all constants usage are errors. WengArticle: 108204
Weng Tianxiang wrote: > Mike Treseler wrote: > > Weng Tianxiang wrote: > > > > > I even deleted all work directory contents, recompile every modules, > > > but constants in the global package still don't change. > > > > Maybe they are declared in more than one place. > > > > -- Mike Treseler > > Hi MIke, > Never! > > I tried to move all constant definitions from package entity module to > package body module, all constants usage are errors. > > Weng Hi, Is it possible that the error happens because I have used 2 levels of constants: constant DATA_BITS : integer := 16; <-- I change this value, constant DATABITS : integer := DATA_BITS; <-- this value doesn't change WengArticle: 108205
Well, I think this is your simulation bench (or the working toplevel, no matter). To work properly, Modelsim needs all the mentioned vhdl-files. Typically you will create a project, add all the required files, and do a recompile on the particular file, once you edited it. Perhaps you choose "compile" manually in Modelsim and click on the tenth.hdl. Maybe it does not compile due to an error ...Article: 108206
zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote: > Uwe, > Did you have a chance to try my patch? The patches seem right, but the whole thing doesn't work when the windrvr6 module is unloaded. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 108207
I've tested Impact without windriver and was working. Unfortunately I have no access to Impact running on Linux :( Zoltan Uwe Bonnes wrote: > zcsizmadia@gmail.com <zcsizmadia@gmail.com> wrote: > > Uwe, > > > Did you have a chance to try my patch? > > The patches seem right, but the whole thing doesn't work when the windrvr6 > module is unloaded. > > Bye > -- > Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 108208
dhruvakshad@gmail.com wrote: >I am designing a frame grabber .The frame input is expeted at a very >slow rate of 10mbps. I have 4 state machine strutures running at plb >clock rate of 80mhz. I am not able to synchronize the capture of the >packets properly. I am using a triemac ip from xilinx. The triemac >works fine and does take in all the packets. However I get problem in >the state machine part. The out put of state machines doesnt give >proper results. When I run xps I get following warnings : > >1) wwww may have excessive skew because 73 NON-CLK pins failed to route >using a CLK template > >2) xxxx may have excessive skew because 3 CLK pins failed to route >using a CLK template. > >3) yyyy may have excessive skew because 10 CLK pins and 6 NON_CLK >pins failed to route using a CLK template. These are bogus messages (see www.xilinx.com) >wwww is a 2.5mhz clock signal( triemac ) dervied from 25mhz onboard >clock by using a simple counter.This is the rate at which input is >coming in. >The signals xxxx and yyyy are asynchronous signals which are gating >the state machines.These signals are running at far lower rate . >Should I use bufg or FDDRs to route these signals to statemachines ? No, you should use flipflops (FD) to get these signals into the same clock domain as the statemachine. Any asynchronous signal must be buffered by 1 and only 1 flipflop to get your circuit to work reliably. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 108209
>>you can put "API trace logs" read write to physical IO? If they are using the HAL.DLL functions READ_PORT_UCHAR, WRITE_PORT_UCHAR (or WRITE_PORT_xxx, READ_PORT_xxx). This is suggested by MS instead of using in/out directly. I've checked xpc4drvr.sys. It's using READ_PORT_UCHAR and WRITE_PORT_UCHAR. This should be fairly simple. Unfortunately windriver6 implemented all of these functions (I guess because of Linux). I've opened it a disassembler, and they have a bunch of small wrapper functions to read/write I/O. Those functions can be hooked, but it would be nasty. Zoltan Antti wrote: > zcsizmadia@gmail.com schrieb: > > > cblsrv emulates a Par III cable, so Impact doesn't have any idea, > > cblsrv would use a Platform USB cable. One working firmware would be > > good enough (unless they change the cableserver protocoll when using > > Par III) > > > > The windows debugging part is fairly easy, no breakpoints, or anything > > nasty, just simply put API trace logs with dumping incoming/outgoing > > data. > > > > I'd be more interested to reverse engineer the Platform USB than Par > > IV, because most new laptops and some desktops lack par ports anyway. > > > > Reverse engineer the Digilent USB JTAG cable took roughly 2 days to > > reverse engineer the basic protocol, but maybe the Platform USB is much > > nastier. > > > > Zoltan > > > > ah? I am gettin old or what? > you can put "API trace logs" read write to physical IO? > to reverse the Cable IV that is required. > > as of platform USB cable, it makes sens to use the natice cableserver > as gateway, so you are not troubled with the USB protocol or firmware > revision, etc > > AnttiArticle: 108210
zcsizmadia@gmail.com wrote: > > Reverse engineer the Digilent USB JTAG cable took roughly 2 days to > reverse engineer the basic protocol, but maybe the Platform USB is much > nastier. Given how inexpensive the digilent USB cable is, seems like it would make sense to get that working and just forget about the xilinx usb cable?Article: 108211
Andreas Ehliar wrote: > On 2006-09-06, Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote: > > "The standalone Xilinx Platform Cable USB is unsupported and untested. Since > > its hardware is presumably very similar, it may be usable as-is or with some > > minor hacking. " > > I have tested it and it doesn't work. One problem is that the CPLD on the > platform cable does not get a supply voltage at all if the xup firmware is > downloaded to the FX2 chip. That sounds as much like an invitation to a solution as a problem... the FX2 chip has decent documentation, right? And you can figure out which pin should be supplying the CPLD... so change the firmware to be downloaded accordingly. And then go after the data signals if it still doesn't work.Article: 108212
J Thomas wrote: > rickman wrote: > > >>Yes, there are few advantages to a Gray code counter. But one is a >>lower power consumption because only one bit changes on each increment. >> Again this is unlikely to be noticed in a real chip given the small >>size of the counter. > > > If you're getting your code from offchip, and you need a new address > every time you get a new instruction, then the power consumption > advantage might add up, right? > > To my way of thinking this is a braindead way to get code to a > processor, but it seems to be standard. Generating a new address each time is certainly widespread, but there are small pockets where this is done better. Some game machines have a smarter ALE + Counter scheme, and some flash devices have Multi Cycle ALE +Clock schemes ( and Serial flash memories all generates an address, and then streams the data ) There are sync memories that have limited page-burst sizes, but they are complex to use efficently. -jgArticle: 108213
"Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> writes: > "Jim Stewart" <jstewart@jkmicro.com> wrote > > An SCR, placed across the terminals of a decent > > sized gelcell will give a very rewarding blue > > flash followed by an orange fireball after it's > > been turned on. > > We used to put those 0.5mm pencil fillings across the 220V terminals (the > screw type that also accepts banana plugs) at the test benches at school.... > Especially the softer types (4-6B) produced a nice soft orange flash > followed by enormous amounts of smoke :-) Tantalum caps connected with reverse polarity will make a good-sized bang when the encapsulation material bounces off a hard object and/or will have a small mushroom-shaped cloud rise from it. If you happened to be looking at the moment when power was applied to the old UV-erasable PROMs place in a socket backward would put on an interesting show of little pinpricks of light appearing at random spots on the die.Article: 108214
Michael A. Terrell wrote: > > > > Ernie wasn't very happy by the time it was over, then was forced to > quit or be fired a few months later at a time when my word could have > let him keep his job. On top of that, I got ten times what he did for > my Christmas bonus that year. I made almost twice what he got that > year, then he was looking for another job with the company telling his > prospective new employers that they couldn't comment till the lawsuit > was settled. :) > > > > Had a similiar situation when I worked on the 91 Express lanes toll road. My boss was a real A-hole, who would do things like, pull out a knife and shave his arms, commenting on how sharp it was, while asking for the status of your assignments. The threat was very thinly veiled... Then, about 9 months later, I was working for the other toll road company and he came in for an interview. For some reason, he wasn't hired... 8-) CharlieArticle: 108215
rickman schrieb: > Yes, there are few advantages to a Gray code counter. But one is a > lower power consumption because only one bit changes on each increment. Whereas a binary counter changes two bits on average. (1 + 1/2 + 1/4 + ....) This saves you what, 5fW? And that is probably more than offset by more switching internal signals in an FPGA implementation. Kolja SulimmaArticle: 108216
rickman schrieb: > J Thomas wrote: > At > that size the power difference would be virtually unmeasureable. Ripple carry counter power is independant of counter size. (Except for clock tree power) KoljaArticle: 108217
Everett M. Greene wrote: > "Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> writes: > >>"Jim Stewart" <jstewart@jkmicro.com> wrote > > >>>An SCR, placed across the terminals of a decent >>>sized gelcell will give a very rewarding blue >>>flash followed by an orange fireball after it's >>>been turned on. >> >>We used to put those 0.5mm pencil fillings across the 220V terminals (the >>screw type that also accepts banana plugs) at the test benches at school.... >>Especially the softer types (4-6B) produced a nice soft orange flash >>followed by enormous amounts of smoke :-) > > > Tantalum caps connected with reverse polarity will make > a good-sized bang when the encapsulation material > bounces off a hard object and/or will have a small > mushroom-shaped cloud rise from it. > > If you happened to be looking at the moment when power > was applied to the old UV-erasable PROMs place in a > socket backward would put on an interesting show of > little pinpricks of light appearing at random spots > on the die. I remember that. We called it the "You put the chip in the socket backwards lamp". BTW, the SCR trick works best with parts in a TO-220 package.Article: 108218
Hi, The default font of the source window in Modelsim III 6.1e is too large. Although it is changed after I set it in "Tools-Edit Preferences", it goes back the default value the next time I open Modelsim. How can I avoid this? Thank you very much.Article: 108219
rickman wrote: > I guess it has been too long since I have used the SRL. I had > forgotten that the read port was addressable, but that only makes > sense. For a fixed delay shift register these inputs are just hard > connected which is the way I have always used the SRLs. > > I have not used them in many years. I guess they are mostly useful for > signal processing which I don't seem to do much anymore. Otherwise I > don't have many apps where delays are a good thing. > The SRL16's are actually one of the most versatile blocks on the FPGA. You can use them for: reprogrammable LUTs --poor man's reconfiguration dual port memory --serial write port, parallel read synchronous FIFO --smallest FIFO implementation data reordering --this is really cool for sorting and other apps counters state machines variable delays fixed delays The only one of these that is inferred by synthesis tools is the fixed delay, and that is also the least interesting out of all these. I've probably used them for other things as well, but these are the ones that pop out at me. It is a shame that Xilinx doesn't promote the usefulness of the SRL16 more than they do, as I suspect most users don't have a clue how powerful these little buggers are.Article: 108220
radarman wrote: > Thomas Stanka wrote: > >>Torsten Alt schrieb: >> >>>Another thing is that i would try to avoid to compare values with >>>"greater " or "lower" than a value. This can increase your logic since >>>the synthesizer has to synthesize all this cases. In your case i would >> >>I disagree. Using '=' for counters may decrease your logic but may also >>increase your logic[1]. But it will always be a pitfall, if your >>counter value gets over (for inc-counter, else under)) the value your >>looking for, due to any reason. >>I just had to remove a bug from a co-designer basing on this pitfall. >> >>For a simple counter there are only external reasons like SEU that will >>lead to this pitfall, in complex designs, there might be a erroneous >>written if-then-else path leading to the situation were your counter >>waits forever. >> >>bye Thomas >> >>[1] A 8 bit '=' needs 15 XOR2. A 8 bit '> 127' is free in terms of >>gates. > > > Having seen almost every error one can make with counters, I prefer > free-running counters with reload logic. This implies that the counter > can never get "stuck". If, for some reason, the counter manages to > enter an illegal state, it will self-correct. This usually implies that > at least a small period will be garbage, but the system won't fail. > > Also, while it sometimes it does make sense to make a counter 1 bit > wider than the actual count, and use the MSB as a reload signal, you > have to be careful. If you exceed the maximum length of a carry chain, > the P&R tools will break the counter up, and you may lose more > performance than if you had made the counter the exact width. > > Of course, with most of my designs the reload value is never a power of > 2, or the counter is under software control, so I typically write them > the "normal" way anyway. > You've got to make a pretty big counter before synthesis breaks it up. The MSB to reload trick actually works quite well, even for non-power-of-2 and programmable counters. The trick is to load the counter with the complement of the count (or load it with the count and decrement). It is nice because it provides a direct decode of the terminal count and can be accomplished in one layer of logic if the load value is computed correctly.Article: 108221
Hi can someone please explain to me how to post to usenet?Article: 108222
Hi i have 3 X Spartan 3 to configure i followed the Master Serial configuration from the application note, but the sample only has 2 device to configure (i.e. Master FPGA and Slave FPGA); and the M0-M2 pins for the Master are connected to GND and to 2.5V with Slave. If i have 3 fpga to configure i have only one PROM, i will have a PROM, MASTER, SLAVE1, SLAVE2. etc. chain will the M0-M2 pins tied to 2.5 for all Slave FPGA? How about the JTAG for configuring the PROM? How about the Pull-Ups? Thanks.Article: 108223
"phaeton" <blahbleh666@hotmail.com> wrote in message news:1157579221.974696.109440@e3g2000cwe.googlegroups.com... > Hi can someone please explain to me how to post to usenet? Use extra postage.Article: 108224
phaeton wrote: > Hi can someone please explain to me how to post to usenet? Um, you just did...
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