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
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. 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 ? -DArticle: 108176
Ray Andraka wrote: > rickman wrote: > > > Can you use the SRL as a FIFO? I was not aware that you could change > > the length. I thought that was a configuration setting. If they are > > doing that the only extra for the moving pointers would be the 4 bit > > write address counter. > > > > YOu sure can. I think a synchronous fifo was the very first macro I > wrote for the SRL16, before I could even get a part with them in it. > > To use it as a FIFO, you use an SRL16 (or several in parallel for > multi-bit) plus an up-down counter. Push activates the SRL16's write > enable and increments the count. Pop just decrements the count. The > count addresses the SRL16 read port. If you make the counter 5 bits and > preload it with "11111" then you get an empty indication from the > counter's msb for almost free. 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.Article: 108177
Never (never ever!) control a state machine with signals that are asynchronous to the state machine clock. Synchronize or double-synchronize the signals before they touch the state machine. Peter Alfke ========== 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. > 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 ? > -DArticle: 108178
zcsizmadia@gmail.com wrote: > Hi All, > > Here is a open-source CableServer replacement,ent for Impact. Currently > Parallel III and Alter ByteBlaster are supported, but any 3rd party can > be implemented easily and can be used from Impact. > > I've tested only Impact 8.2, if anybody has any problem with 7.1, > please let me know! > > Impact and Xilinx CableServer communication are very pooly written. > There is no error recovery at all. If server stops, Impact GUI will > crash. To avoid this you must disconnect server from GUI using > Output/Cavble disconnect menu. > > http://sourceforge.net/projects/xilprg > http://sourceforge.net/project/showfiles.php?group_id=175344&package_id=203209 > > Regards, > > Zoltan > Dear All, This is good news. About time to get some open software to program FPGA's!. The problem I still have is that we and many others are using the USB Parallel IV cable (DLC7). Who has ideas or works on an interface to drive the DLC7 cable? It seems to me that it now should be possible to build an USB interface to communicate with the DLC7. First someone needs to 'investigate' the functions of the Cypress firmware and then with the knowledge of the Impact protocol .... Regards, Rene.Article: 108179
Rene van Leuken schrieb: > zcsizmadia@gmail.com wrote: > > Hi All, > > > > Here is a open-source CableServer replacement,ent for Impact. Currently > > Parallel III and Alter ByteBlaster are supported, but any 3rd party can > > be implemented easily and can be used from Impact. > > > > I've tested only Impact 8.2, if anybody has any problem with 7.1, > > please let me know! > > > > Impact and Xilinx CableServer communication are very pooly written. > > There is no error recovery at all. If server stops, Impact GUI will > > crash. To avoid this you must disconnect server from GUI using > > Output/Cavble disconnect menu. > > > > http://sourceforge.net/projects/xilprg > > http://sourceforge.net/project/showfiles.php?group_id=175344&package_id=203209 > > > > Regards, > > > > Zoltan > > > > Dear All, > > This is good news. About time to get some open software to program FPGA's!. > > The problem I still have is that we and many others are using the USB > Parallel IV cable (DLC7). Who has ideas or works on an interface to > drive the DLC7 cable? It seems to me that it now should be possible to > build an USB interface to communicate with the DLC7. First someone needs > to 'investigate' the functions of the Cypress firmware and then with > the knowledge of the Impact protocol .... > > Regards, > > Rene. not exactly, you are messing some things. Parallel Cable IV = DLC7, does not work on USB dongle Platform USB Cable = DLC9 if you need to communicate with DLC9 then you use the original xilinx cable server and use the ip protocol to talk to it. no need to know anything internal to the DLC9. if you want to make impact to communicate with some USB cable other than DLC9 then you have to add support for it to the opensource cable server. This could also be a special USB2LPT type of thing that is later connected to DLC7 but that doesnt make much sense. AnttiArticle: 108180
Austin Lesea wrote: > Pomerado, > > The Vcc_config must stay powered, the Vcc_aux must stay powered, and the > Vccint must stay powered. > > If any of these drops below their power on reset thresholds, the device > erases all memory before trying to configure. > > Vcco_config POR trip is ~ 0.5 to 0.75V > Vcc_aux POR trip is ~1.3 to 1.8V > Vccint POR trip is ~0.5 to 0.75V > > I recommend that you may lower each supply only to what is specified in > the recommended operating conditions table of the data sheet, and no less. > > This, of course, after you place the design in a state where all clocks > are disabled, IOs tristate, and just waiting for a signal on an IOB pin > to wake up, and start processing from where it left off. > > Table 4 is where you will find the min currents: > http://direct.xilinx.com/bvdocs/publications/ds302.pdf The configuration user guide states that during the configuration memory input phase, the only I/O power that is needed is VCCo_0 (also known as VCCconfig), to drive the configuration data clock output. >From Virtex-4 Configuration Guide, p. 16: "None of the I/O voltage supplies (VCCO), except VCCO_0 (VCC_CONFIG), need to be powered for Virtex-4 configuration in JTAG or serial modes." >From Virtex-4 Packaging and Pinout Specification, p. 16: VCCAUX Input Power-supply pins for auxiliary circuits VCCINT Input Power-supply pins for the internal core logic >From Virtex-4 Data Sheet: DC and switching characteristics: VDRINT Data retention VCCINT voltage (below which configuration data might be lost) 0.9 V VDRI Data retention VCCAUX voltage (below which configuration data might be lost) 2.0 V Recommended operating conditions: VCCint 1.2V VCCaux 2.5V ICCINTQ Quiescent VCCINT supply current XC4VLX60 167 mA ICCAUXQ Quiescent VCCAUX supply current XC4VLX60 74 mAArticle: 108181
Rene van Leuken <rene@cas.et.tudelft.nl> wrote: ... > The problem I still have is that we and many others are using the USB > Parallel IV cable (DLC7). Who has ideas or works on an interface to > drive the DLC7 cable? It seems to me that it now should be possible to > build an USB interface to communicate with the DLC7. First someone needs > to 'investigate' the functions of the Cypress firmware and then with > the knowledge of the Impact protocol .... Have a look at http://inisyn.org/src/xup/ It states: "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. " So well worth a try. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 108182
http://www.fpga-faq.com/FAQ_Pages/0027_Creating_PCB_symbols_for_FPGAs_using_ORCAD.htm <in_spb3@yahoo.com> wrote in message news:1157529723.621343.306750@b28g2000cwb.googlegroups.com... > Hello. > Do anybody have ORCAD library for Xilinx xc3s1500 in FG320 package and > TI TMS320C6713BGDP300? > Thanks, > Dmitry. >Article: 108183
I think later on it would be nice to support all Xilinx programmer cables natively from cblsrv (Platform USB, Parallel IV, etc.): 1. Jungo driver could be eliminated on both Linux and Win32 2. A open-source "cblhost" could be easily written and bundled with cblsrv supporting standard Xilinx cables + 3rd party cables Zoltan Antti wrote: > Rene van Leuken schrieb: > > > zcsizmadia@gmail.com wrote: > > > Hi All, > > > > > > Here is a open-source CableServer replacement,ent for Impact. Currently > > > Parallel III and Alter ByteBlaster are supported, but any 3rd party can > > > be implemented easily and can be used from Impact. > > > > > > I've tested only Impact 8.2, if anybody has any problem with 7.1, > > > please let me know! > > > > > > Impact and Xilinx CableServer communication are very pooly written. > > > There is no error recovery at all. If server stops, Impact GUI will > > > crash. To avoid this you must disconnect server from GUI using > > > Output/Cavble disconnect menu. > > > > > > http://sourceforge.net/projects/xilprg > > > http://sourceforge.net/project/showfiles.php?group_id=175344&package_id=203209 > > > > > > Regards, > > > > > > Zoltan > > > > > > > Dear All, > > > > This is good news. About time to get some open software to program FPGA's!. > > > > The problem I still have is that we and many others are using the USB > > Parallel IV cable (DLC7). Who has ideas or works on an interface to > > drive the DLC7 cable? It seems to me that it now should be possible to > > build an USB interface to communicate with the DLC7. First someone needs > > to 'investigate' the functions of the Cypress firmware and then with > > the knowledge of the Impact protocol .... > > > > Regards, > > > > Rene. > > not exactly, you are messing some things. > Parallel Cable IV = DLC7, does not work on USB dongle > Platform USB Cable = DLC9 > > if you need to communicate with DLC9 then you use the original > xilinx cable server and use the ip protocol to talk to it. > no need to know anything internal to the DLC9. > > if you want to make impact to communicate with some USB cable > other than DLC9 then you have to add support for it to the opensource > cable server. This could also be a special USB2LPT type of thing that > is later connected to DLC7 but that doesnt make much sense. > > AnttiArticle: 108184
This indicates to me that "xcounter : tenths" is not present. Does it exit in your "work" directory? Has it been compiled correctly, without an error ?Article: 108185
Thank you. alterauser wrote: > This indicates to me that "xcounter : tenths" is not present. Does it > exit in your "work" directory? Has it been compiled correctly, without > an error ? No. It is not in the work directory. How and where (In modelsim?) to compile the .vho file?Article: 108186
zcsizmadia@gmail.com schrieb: > I think later on it would be nice to support all Xilinx programmer > cables natively from cblsrv (Platform USB, Parallel IV, etc.): > > 1. Jungo driver could be eliminated on both Linux and Win32 > 2. A open-source "cblhost" could be easily written and bundled with > cblsrv supporting standard Xilinx cables + 3rd party cables > > Zoltan > its not that easy. specially if you want to use unmodified cable IV and usb cable. for usb cable it is possible to use replacement firmware and pld file, but it want be any more xilinx platform usb cable then. similarly the pld in Cable IV can be read out and reprogrammed. if you are interest to support Cable IV in Cable IV high speed mode I can give jedec2vhdl converter that can create VHDL code from the jedec file read back from Cable IV, it should be enough to reverse the Cable IV low level protocol I think. I tried to revers Cable IV by creating an PCI IP Core that emulated the cable and logged the transactions, but that way didnt leed to success, ok I did not have time to have proper ECP emulation that was the reason why I didnt succeed with that attempt. AnttiArticle: 108187
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
Article: 108188
alterauser wrote:
> During the synthesis process, Quartus reports "Ignoring invalid
> Fast-IO-Timing Assignments" which I am not able to discover, since
> Quartus does not say WHERE or WHICH assignment is set incorrectly. Any
> Idea ?
I would start a new project with a clean
working directory and default assignments
except for the file list.
Do:
Processing, Start, Analysis + Synthesis
Once that works start adding other
assignments one at a time.
-- Mike Treseler
Article: 108189Has anyone else experienced the fault with the ISE Simulator "ERROR:Simulator:222 - Generated C++ compilation was unsuccessful". The Answers Database is no use at all. More importantly has anyone found out how to get around it? I've gone from working just fine to completely stuck! TIA, Rog.Article: 108190
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 Antti wrote: > zcsizmadia@gmail.com schrieb: > > > I think later on it would be nice to support all Xilinx programmer > > cables natively from cblsrv (Platform USB, Parallel IV, etc.): > > > > 1. Jungo driver could be eliminated on both Linux and Win32 > > 2. A open-source "cblhost" could be easily written and bundled with > > cblsrv supporting standard Xilinx cables + 3rd party cables > > > > Zoltan > > > its not that easy. specially if you want to use unmodified cable IV and > usb cable. for usb cable it is possible to use replacement firmware and > pld file, but it want be any more xilinx platform usb cable then. > > similarly the pld in Cable IV can be read out and reprogrammed. > > if you are interest to support Cable IV in Cable IV high speed mode I > can give jedec2vhdl converter that can create VHDL code from the jedec > file read back from Cable IV, it should be enough to reverse the Cable > IV low level protocol I think. > > I tried to revers Cable IV by creating an PCI IP Core that emulated the > cable and logged the transactions, but that way didnt leed to success, > ok I did not have time to have proper ECP emulation that was the reason > why I didnt succeed with that attempt. > > AnttiArticle: 108191
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. /AndreasArticle: 108192
Yuu must compile it, just like any other hdl file. Assuming you have a simulation wrapper for your design containing all IO parts of the FPGA which are not physically present, you just copy this wrapper into a new file and replace the complete design by the vho. Did you allready succed in compling and simulating the complete design, or parts of the design?Article: 108193
Hi Mike, yes of course I did that (in fact I partly disabled one contraints after another) - but I think it should be more convenient to be pointed directly to an errar, rather than doing research on this, since the next error like this will appear shortly most likely...Article: 108194
alterauser wrote: > Yuu must compile it, just like any other hdl file. > > Assuming you have a simulation wrapper for your design containing all > IO parts of the FPGA which are not physically present, you just copy > this wrapper into a new file and replace the complete design by the > vho. > > Did you allready succed in compling and simulating the complete design, > or parts of the design? In ISE, I can see tenths.xco file at the source tab. I can see tenths.vhd and tenths.xco at the library tab. Although I cannot go on the behavioral simulation, it can go with the post-translate simulation. I don't know why the behavioral simulation cannot do. Thank you.Article: 108195
alterauser wrote:
> Yuu must compile it, just like any other hdl file.
>
> Assuming you have a simulation wrapper for your design containing all
> IO parts of the FPGA which are not physically present, you just copy
> this wrapper into a new file and replace the complete design by the
> vho.
>
> Did you allready succed in compling and simulating the complete design,
> or parts of the design?
This top file includes the component description of tenths. Is it
enough?
library IEEE;
use IEEE.std_logic_1164.all;
--synopsys translate_off
library UNISIM;
use unisim.vcomponents.all;
--synopsys translate_on
entity stopwatch is
port ( CLK : in STD_LOGIC;
RESET : in STD_LOGIC;
STRTSTOP : in STD_LOGIC;
TENTHSOUT : out STD_LOGIC_VECTOR(9 downto 0);
ONESOUT : out STD_LOGIC_VECTOR(6 downto 0);
TENSOUT : out STD_LOGIC_VECTOR(6 downto 0));
end stopwatch;
architecture inside of stopwatch is
component statmach
port ( CLK : in STD_LOGIC;
RESET : in STD_LOGIC;
STRTSTOP : in STD_LOGIC;
locked : std_logic;
CLKEN : out STD_LOGIC;
RST : out STD_LOGIC);
end component;
COMPONENT testip
PORT(
RST_IN : IN std_logic;
CLKIN_IN : IN std_logic;
LOCKED_OUT : OUT std_logic;
CLK0_OUT : OUT std_logic;
CLKIN_IBUFG_OUT : OUT std_logic
);
END COMPONENT;
component tenths
port (
Q: OUT std_logic_VECTOR(3 downto 0);
CLK: IN std_logic;
Q_THRESH0: OUT std_logic;
CE: IN std_logic;
AINIT: IN std_logic);
end component;
Article: 108196zcsizmadia@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: 108197
Thomas Stanka schrieb: > 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. > Hei, a 8 bit "=" needs at maximum 7 AND2 and 7 INV not 15 XOR2. And of course is a compare larger 2^n-1 always for free since you only have to check the n-bit. But this is a special case. In most cases your logic will increase. On can calculate it theoretically by dividing a n-bit comparator into m n/m-bit comparators + the glue logic. So for a 16-bit comparator one can split it into 2x8-bit or 4x4-bit or 8x2-bit. The size of the splitting can be adapted to the width of the LUTs in case of an FPGA. SEU are a different story but if this can happen in your environment then the counter is your smallest problem. The point with complex designs and if-else paths are that i would simply not use nested and long if-else paths cause you leave the implementation of your design to the synthesis tools. They are pretty good if it comes to standard design elements like comparators, counters, registers etc. But they are pretty bad if it comes to synthesize VHDL code which is written like C. Also your design will be prone to latches if you don't take care about the path coverage. The method of radarman is a nice one. Compare equal to a value and take a MSB as a security check to reinitialize the counter in case something went wrong. Bye, TorstenArticle: 108198
alterauser wrote:
> Hi Mike, yes of course I did that (in fact I partly disabled one
> constraints after another)
So, what did you find?
Where was the error coming from?
> - but I think it should be more convenient to
> be pointed directly to an errar, rather than doing research on this,
> since the next error like this will appear shortly most likely...
If you can't find a workaround, call the "man"
http://www.altera.com/support/spt-index.html
-- Mike Treseler
Article: 108199zcsizmadia@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 ----------
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