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
Ed McGettigan wrote: > Laurent Pinchart wrote: >> Because iMPACT requires the Jungo binary driver, which has serious >> security >> issues. >> >> Linux offers a user-space USB library called libusb (available for >> win32 as >> well) which would let iMPACT access the Platform Cable USB without >> using a >> binary kernel driver. >> >> As I can't modify iMPACT to get rid of the Jungo dependency, I went the >> other way and tried to write a simple command line software to drive the >> cable. Unfortunately, the USB protocol seems to be classified top secret, >> and reverse engineering the EZUSB firmware didn't give me enough >> information. That's why I asked for more information on here. >> >> Laurent Pinchart >> > > I've never heard of any Linux security issue with the Jungo drivers > and a quick Google search produced nothing indicating any problems. There > was a single discussion on freshmeat.net in the windriver project, but > there > was no conclusive or specific issue mentioned and no other net sources. > > Based on the first comment on the freshmeat.net site by "omerz" it appears > that you could put superuser/root permissions on the driver that > theoretically > could be misused, but if don't leave it as root then you get just normal > user permissions. > > It seems like you want to go to whole lot of effort to redo work that > already exists and ships for free. If so, then I guess everyone needs > a hobby to work on. > > If you could cite a single instance of Linux box being "owned" through a > Jungo USB/Parallel driver exploit I would be interested in seeing the > reference. > > Ed McGettigan > -- > Xilinx Inc. The security problem is more like : "I don't want foreign closed-source code running in kernel-mode on my machine". And linux is "supported" well ... I never managed to make the usb cable work on linux (not a redhat) ... SylvainArticle: 102501
This wasn't apparant from your earlier postings. Wanting to program an FPGA with a USB device under Linux seems like it should already exist, and I understrand your frustration that it doesn't. Seems to me it would be possible to write an adaptation layer for an existing device. So all you need is a device you understand. That can be fixed.....Article: 102502
Hy I'am a student at a technical unniversity. one of my projects it's to test an PID regulator implemented on a Spartan3 board. Because i'm a newbie in vhdl programing the code that I wrote didn't work. If someone have any ideas or an example of a PID regulator code please send me an email . best regards CLausArticle: 102503
Hi, check www.opencores.com MarcoArticle: 102504
>Hy > I'am a student at a technical unniversity. one of my projects it's to >test an PID regulator implemented on a Spartan3 board. Because i'm a >newbie in vhdl programing the code that I wrote didn't work. If someone >have any ideas or an example of a PID regulator code please send me an >email . best regards CLaus You'll learn more if you solve the problem yourself. Isn't this why you're at university?Article: 102505
> When plastic packages with absorbed moisture > are run through a molten solder bath... It's true that some manufacturers use wave soldering for surface-mount devices, but this isn't recommended. However, there is a similar problem with conventional surface-mount assembly. > You be the judge whether this is the real reason > for the minimum purchase quantity requirements. Of course, they'd have less excuse if manufacturers offered prototype devices (presumably at a premium) in smaller trays (like 1x1). Is this rocket science?Article: 102506
Hi Peter, Indeed, I was confused. I saw Steve's reply and was unwillingly referring to Spartan3. There started the confusion. My appologies. Luc On 16 May 2006 14:51:31 -0700, "Peter Alfke" <peter@xilinx.com> wrote: >Luc, let me un-confuse you: >I referred to Virtex-4, but why do you ask? >The OP did not specify a device family, and Virtex always outperforms >Spartan. >And Spartan is always lower priced than Virtex. >That's why we have the two different families. >I do not understand the reason for your question. > >Peter Alfke, Xilinx ApplicationsArticle: 102507
Laurent Pinchart <laurent.pinchart@skynet.be> wrote: ... > As I can't modify iMPACT to get rid of the Jungo dependency, I went the > other way and tried to write a simple command line software to drive the > cable. Unfortunately, the USB protocol seems to be classified top secret, > and reverse engineering the EZUSB firmware didn't give me enough > information. That's why I asked for more information on here. I have adapted so xc3stools can talk to XC3S via the FT2232 on USB. If you are interested, talk to me. Otherwise, I understand your concerns about WinDriver. It's the first thing that gives you trouble when you come back to ISE after some time. As one probaly upgraded the kernel in the meantime, you first have to hunt for a fitting Windriver. And that for a task that could be done with on board means (parallel port access with /dev/parport and usb access vin /proc/bus/usb). As a hint for the Xilinx developpers: Libusb exists for Win32 too. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 102508
>>> Because iMPACT requires the Jungo binary driver, which has serious >>> security >>> issues. >>> >>> Linux offers a user-space USB library called libusb (available for >>> win32 as >>> well) which would let iMPACT access the Platform Cable USB without >>> using a >>> binary kernel driver. >>> >>> As I can't modify iMPACT to get rid of the Jungo dependency, I went the >>> other way and tried to write a simple command line software to drive the >>> cable. Unfortunately, the USB protocol seems to be classified top >>> secret, and reverse engineering the EZUSB firmware didn't give me enough >>> information. That's why I asked for more information on here. >>> >>> Laurent Pinchart >>> >> >> I've never heard of any Linux security issue with the Jungo drivers >> and a quick Google search produced nothing indicating any problems. There >> was a single discussion on freshmeat.net in the windriver project, but >> there >> was no conclusive or specific issue mentioned and no other net sources. >> >> Based on the first comment on the freshmeat.net site by "omerz" it >> appears that you could put superuser/root permissions on the driver that >> theoretically >> could be misused, but if don't leave it as root then you get just normal >> user permissions. >> >> It seems like you want to go to whole lot of effort to redo work that >> already exists and ships for free. If so, then I guess everyone needs >> a hobby to work on. >> >> If you could cite a single instance of Linux box being "owned" through a >> Jungo USB/Parallel driver exploit I would be interested in seeing the >> reference. >> >> Ed McGettigan >> -- >> Xilinx Inc. > > The security problem is more like : "I don't want foreign closed-source > code running in kernel-mode on my machine". That's not the only issue. The main problem is that the Jungo driver is a security hole by design: it gives applications access to PCI cards from user space without any security check, making it possible for any user to read from and write to any memory location. The people who designed such a piece of crap should be banned from using computers for the rest of their life. Mind you, Jungo is not the only company who makes money from creating security holes. Macrovision, with its copy protection systems (SafeDisc for instance) introduced similar problems: the copy protection system loads a Windows kernel drivers which can be used by any application to read from or write to kernel memory. I could also mentionned the recent problems with the Sony copy protection on audio CDs... But Sylvain is right: even if the security hole in the Jungo products wasn't so wide, I don't want closed-source code running in kernel mode. Running untrusted user-space applications is one thing, running untrusted kernel-mode code is another. > And linux is "supported" well ... I never managed to make the usb cable > work on linux (not a redhat) ... I've managed to scan the JTAG chain once with iMPACT, but it never worked again. The CPLD version is misread nearly each time, making iMPACT insist on updating the CPLD (and that takes a *lot* of time, as each JTAG bit toggling operation is implemented as a separate USB command). Laurent PinchartArticle: 102509
Hi Uwe, > I have adapted so xc3stools can talk to XC3S via the FT2232 on USB. If you > are interested, talk to me. Can you give me more information ? A quick search for xc3stools on google didn't return any hit. > Otherwise, I understand your concerns about WinDriver. It's the first > thing that gives you trouble when you come back to ISE after some time. As > one probaly upgraded the kernel in the meantime, you first have to hunt > for a fitting Windriver. And that for a task that could be done with on > board means (parallel port access with /dev/parport and usb access vin > /proc/bus/usb). As a hint for the Xilinx developpers: Libusb exists for > Win32 too. That was one of my points: why use a closed-source kernel-mode driver so badly designed that it insults all kernel developers when an open-source, free software multiplatform solution is available ? Laurent PinchartArticle: 102510
rickman wrote: > I don't know about stupid, but I didn't see the equations... :) I > just used the stated feedback voltage and the resistor ratios to get my > numbers. I don't know why your numbers are different from mine. What > equations did you use? I used Vf * (R1+R2/R2), where R1 is the > resistor that connects to the output voltage and R2 is the resistor > that connects to ground. Ahhh, thanks to your persistence, I have spotted what I was missing. Yes, indeed, there was a certain amount of stupidity involved, I'd be the first to admit. The datasheet states a value of Vfb of 1.24V next to equation 15. Foolishly, I used this, instead of 1.22V as stated earlier in the datasheet (which I've only just noticed). I assume that the 1.24V is the upper tolerance bound 1.22V+2% ~ 1.24V. I'm not quite sure why, it seems a little arbitrary to me to pick one boundary for the example calculation. Thoughts? -- PeterArticle: 102511
Peter Mendham <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> writes: > > The error on 3.3V is 1.3%, which will be nearest fit resistor values. > > Normally, simplest design uses two resistors, and it is hard to nail > > a value under 1% with available values. > > If this is loosing you sleep, then move to a 3 resistor design, and > > also be prepared to pay for resistors under 1% tolerance. > > At the moment, the design is slated as having a three resistor > design. I figured that was the most flexible in terms of layout. If > my paranoia is unfounded then we'll throw in a zero-ohm resistor and > go back to two. > Hopefully a 1% zero ohm resistor :-) Sorry! Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 102512
Thanks Brian for your reply I solve my problem... My Parallel Port was not activated in BIOS ... (sick) So I activate it. Now, it works fine !!! RegardsArticle: 102513
Here are some more details: The output clock is used for CMOS imaging sensor. The input clock can be 200MHz (CLK2X from DCM0) Desired clock increment is about 1 MHz. Maximum jitter not specified. 2 DCMs free for now. I think that DCM with dynamic FX ratios cannot produce such increments, because output frequency can only take fraction ratios according to input clock. I think DDS is the best solution for my problem. The open question is which frequency to take for input: 100, 200, 300 ..MHz? Thank you all, GuruArticle: 102514
it is possible to have virtual clock DDS you can calculate several phaseses per highest useable clock (200MHz) and use one output stage that combines the result, IO DDR primitive, you can so have DDS clock as if it would be 400MHz while still using max 200MHz real clock in the FPGA AnttiArticle: 102515
Guru schrieb: > Here are some more details: > The output clock is used for CMOS imaging sensor. > The input clock can be 200MHz (CLK2X from DCM0) > Desired clock increment is about 1 MHz. > Maximum jitter not specified. Ahhh, now we move forward! > 2 DCMs free for now. > I think that DCM with dynamic FX ratios cannot produce such increments, > because > output frequency can only take fraction ratios according to input > clock. I think DDS is the best solution for my problem. The open > question is which frequency to take for input: 100, 200, 300 ..MHz? Lets look at the worst case. You want 66 MHz max. If we use some kind of 660 MHz master clock, we will have 1/10 UI jitter. Not too bad, not too good. I guess for the CMOS image sensor the jitter wont hurt, since it is read like a ram array, isnt it? So what you need is a multiphase DDS using lets say 4 accus. The MSBs must be parallel-serial converted using a x2 Clock and a DDR output stage. Been there, done that. Do a search in the FPGA FAQ, its explained there. Regards FalkArticle: 102516
MikeShepherd564@btinternet.com schrieb: >>Hy >>I'am a student at a technical unniversity. one of my projects it's to >>test an PID regulator implemented on a Spartan3 board. Because i'm a >>newbie in vhdl programing the code that I wrote didn't work. If someone >>have any ideas or an example of a PID regulator code please send me an >>email . best regards CLaus > > > You'll learn more if you solve the problem yourself. Isn't this why > you're at university? Very good point. And to add, a PID regulator is no good starting point for a VDHL beginner. Start with the hardware "Hello World", a flashing LED. Go on to some counter and state machine stuff. After a while you might be ready for PID. Regards FalkArticle: 102517
Can IO DDR primitive output be used inside FPGA, because I need this clock also for several processes inside FPGA, or I have to route it to output I/O pin and then physically tie it to input I/O pin? By using DDR primitive I can theoretically get only 2.5ns jitter (+ logic delay) at 200 MHz input clock. GuruArticle: 102518
Hi ! I would know if , to your mind, it may be possible to implement a 16 bits Analog-to-Digital Converter on a FPGA ( like a Spartan 3 for example ... ) Any idea is welcome. Thanks.Article: 102519
Guru schrieb: > Can IO DDR primitive output be used inside FPGA, because I need this > clock also for several processes inside FPGA, or I have to route it to > output I/O pin and then physically tie it to input I/O pin? Hmmm? Maybe you can do a trick. Define an bidirectional inout port, drive the output with the DDR FF and use the input as the (generated) clock. This may work. > By using DDR primitive I can theoretically get only 2.5ns jitter (+ > logic delay) at 200 MHz input clock. Logic delay doesnt matter for jitter, the delay is just a static phase shift. If you use a 300 MHz clock, you can go down to 1.6 ns. What device are you using? AFAIK Viertex-II etc. go up to 840 Mbit/s in DDR data transfer, Spartan-3 up to 622 Mbit/s. Regards FalkArticle: 102520
Laurent Pinchart <laurent.pinchart@skynet.be> wrote: > Hi Uwe, > > I have adapted so xc3stools can talk to XC3S via the FT2232 on USB. If you > > are interested, talk to me. > Can you give me more information ? A quick search for xc3stools on google > didn't return any hit. s/xc3stool/xc3sprog -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 102521
Dear all, Mid-Google about something largely unrelated I spotted references to "EdaXML" which seems to be an XML-ified version of EDIF. I was curious about this, but couldn't find much more hard-info. I'm particularly interested in uses for FPGA netlists, hence the post here. I don't know how long this format has been around but can anyone tell me a) how well this format is supported? do any (either?) of the major FPGA vendors care about this format? b) whether there are any (preferably free) tools for converting to/from EDIF? c) any other (relevant) thoughts on this matter? Regards, -- PeterArticle: 102522
Hello, Can anyone give i explanation for the disappointing 550Mhz performance of V5 DSP slices? Couldn't we hope 1GHz multipliers with 65nm technology? By the way, why are not the multipliers pipelined to increase the performance?. Is there any chance to see pipelined multipliers in virtex-6?Article: 102523
<airtom@gmail.com> wrote in message
news:1147862042.233347.292340@j33g2000cwa.googlegroups.com...
> Hello,
> Can anyone give i explanation for the disappointing 550Mhz performance
> of V5 DSP slices? Couldn't we hope 1GHz multipliers with 65nm
> technology?
You can hope for what you like! :) 1GHz multipliers would be very hard to
use if the logic fabric and memories can't keep up. If you can't feed them
with input data they will spend a lot of time doing nothing... do you have
an application in mind that requires 1GHz multipliers? How would you propose
to engineer them into your wider FPGA design?
> By the way, why are not the multipliers pipelined to increase the
> performance?. Is there any chance to see pipelined multipliers in
> virtex-6?
The DSP48E is already pipelined. Obviously, adding extra (bypassable)
pipeline stages within the multiplier would increase the maximum clock
speed, but it also adds latency and silicon area, and increases power
consumption. Everything's a tradeoff...
Note that there are many enhancements in the DSP48E over the Virtex-4 DSP48
block, not the least of which being a larger multiplier (25x18). So a direct
MHz-to-MHz comparison with the previous generation is not entirely fair.
Cheers,
-Ben-
Article: 102524
I found DDS code in comp.arch.fpga archives:
library ieee;
use ieee.numeric_std.all;
use ieee.std_logic_1164.all;
entity dds is
generic(
bits:natural);
port(
clk: in std_logic;
inc: out std_logic_vector;
clk_out: out std_logic);
end dds;
architecture RTL of dds is
signal accum unsigned(bits-1 downto 0);
begin
process(clk)
begin
if clk'event and clk='1' then
accum<=accum+unsigned(inc);
end if;
end process;
clk_out<=accum(bits-1);
end RTL;
Re: Falk: Good indea about bidirectional port. I am using Virtex-4 FX12
SF363 -10.
Thnx, Guru
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