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
the easiest way may be adding a picoblaze to handle the i2
initialization
http://www.dulseelectronics.com/download/download_index.html
there are some examples,
I am using this approuch to initialize chrontel DVI chips and Agilent
smart cameras
on an Virtex-4 board
the DVI application (a pong demo) will soon be added to reference
designs available
online http://hydraxc.xilant.com
basically you use the picoblaze as black box and connect to i2c
the code that initializes ch7301 then is coded as picoblaze assembler,
like her
; Enable DVI power
LOAD sA, 49
LOAD sB, C0
CALL I2C_DVI_WRITE
Antti Lukats
Article: 102976Hi Antti, I suspect that a radiation tolerant 8051 will be even more expensive :-) Cool project! Regards, Hans www.ht-lab.com "Antti" <Antti.Lukats@xilant.com> wrote in message news:1148462241.786718.268930@j33g2000cwa.googlegroups.com... > Hi > > i just realized that a DIP40 module on my desk at work could be the > most expensive 8051 compatible DIP40 thing ever made - its a Virtex-4 > V4LX25 based FPGA module with current manufacturer price (qty 1) of 607 > USD. > > This expensive 51 was developed as support request to help our > customers to use Nexxar to build FPGA applications - the design is > based completly on open-source T51 IP Core from Daniel Wallner > (jesus@opencores ) as that design does not work directly for V-4 I made > the small changes (only change of BRAMs prims) and after copying the > .BIT to mini-SD card, I got: > > HydraXC BIOS 1.0.2.a > MAC: 15E087309014 > Status: > File: BASIC52 .BIT > Loading FPGA > Loading O/S... > *MCS-51(tm) BASIC V1.1* > READY >>10 PRINT "Hello Virtex-4 MCS-51 Basic" >>12 PRINT "--------------------------" >>list > 10 PRINT "Hello Virtex-4 MCS-51 Basic" > 12 PRINT "--------------------------" > > READY >>run > > Hello Virtex-4 MCS-51 Basic > -------------------------- > > READY >> > > ------------ > the above is actual screenshot from terminal, at the place where the > MCS-51 prompt appears I pressed ' ' (space) to invoke the auto-baud > detection. > > funny, after doing it I remembered that I have done some MCS basic work > earlier, porting it to 89S8252 to use internal flash. > > The Virtex-4 version just has the ROM Basic and 32KB XRAM > > the demo design should work on any decent Virtex board all 'porting' > needed would be changing the UCF > > NET CLK LOC = W10; # 12MHz > NET RXD LOC = D6; > NET TXD LOC = E7; > NET RST LOC = W3; > > all the porting was rather simple, but as I am not aware of any 'ready > to run' versions of the T51 IP core, the all project may be interesting > to get started with the T51 IP core in FPGA > > http://hydraxc.xilant.com/CMS/index.php?option=com_remository&Itemid=41&func=fileinfo&id=7 > > the archive contains the full ISE project - no extra tools needed - > just change UCF and FPGA part, resynth and should work :) > > Antti Lukats >Article: 102977
Hi Hans, well actually I was doing the CPU86, demo but it did not work immediatly, looks like some issues with ram read writes, so I did the 8051 port inbetween. I hope to get the CPU86 demo ready soon as well. and yes I bet an attempt to buy a rad-hardened 51 in cerdip-40 today would get very high pricing (if available at all) AnttiArticle: 102978
Kishore wrote > -> Are there things that VHDL does better than verilog or vice-versa It's is much easier to calculate constraints (LOCs and the like) in VHDL. Only applies if you need to do higher performance stuff, when it becomes 100% vital, IMHO. And VHDL is tougher on types, saving some debugging time. I'm not an expert, but I believe the latest Verilog has caught up with VHDL on generate, etc.Article: 102979
amko schrieb: > Hello everybody, > > Currently I am designing very accurate delay generator, which will be > based on FPGA . > This delay generator should have similar technical requirements with > DG535 http://www.thinksrs.com/products/DG535.htm. > The major Delay Generator requirements are > > · 2 ns (1ns is desired, but 2ns will be also ok) time resolution on > delayed channel (it means that time differences between any delayed > channels can be set in 2 ns steps) > · maximal 50 ps - 60ps (RMS) jitter on each output. > · 14 delayed ECL channels > · Two high speed (PECL) inputs (500 Mz ECL clock signal and ECL > trigger) How are you trying to build the delay generator? I see immediately how you can get a resolution of 80ps in a Virtex-4, but I fail to see you can have a low input to output jitter in a clocked design. If you sample the input signal with a GHz clock and use that to generate that clock to generate a delayed ouput you are going to have 1ns jitter in your delay, don't you? Unless you are you doing something fancy like this: http://www-ppd.fnal.gov/EEDOffice-W/Projects/ckm/comadc/tdc1s.pdf Kolja SulimmaArticle: 102980
"bijoy" <pbijoy@rediffmail.com> wrote in message news:ee9b386.-1@webx.sUN8CHnE... > Hi I am facing the following problem during P&R of my design > > =================================== Error - Description Phase 1.1 > ERROR:Place:341 - The design contains 3 Block RAM components that are > configured as 512x36 Block RAMs and 11 Multiplier components. The > Multiplier site adjacent to the location of a 512x36 Block RAM component > must remain free because of resource sharing. Therefore a device must have > at least 14 Multiplier sites for this design to fit. The current device > has only 12 Multiplier sites. > > =================================== > > I am using FFT core with 18-bit as the input data width, then all these > above errors pops up if i reduce the input width to 17-bit, the design > won't give any error. > > can any body help me to sort this problem ?? > > Thanks in advance > Bijoy, Use a bigger FPGA? You've used up all the resources. It works at 17 bit wide, because the multipliers are 17x17, if you're doing signed arithmetic. HTH, Syms. Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.phpArticle: 102981
"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:44736721$1@clear.net.nz...
> johnp wrote:
>
> > XILINX - please change the .ise file back to text format! The binary
> > version is a BAD idea for a bunch of reasons!
>
> Perhaps now is a good time to ask Xilinx for a time-frame, when they
> WILL be making this fix ?
> IIRC there are other threads on the same time-sink flaw ?
I believe the shortcomings of the binary ISE project file format are being
addressed for the next major release.
Yes, I appreciate that this is a rather weasley answer. That's because I
don't have the details of what exactly is going to happen. But I for one am
certainly hoping that we will get an ASCII project file and thus return to
the world of EDA sanity. Of course, there are other possible outcomes, but
I'm trying not to think about them (it's too horrible).
The veritable deluge of complaints - both from customers and from internal
users - has not simply leaked away into the Water Table of Inaction: rather,
it has been funneled through the Downpipe of Customer Support and collected
in the Water Butt of the Change Request System. Some of it is currently
leaking through the Damp-Proof Course of Management. Erm, stop me when I've
taken the analogy too far... :)
Cheers,
-Ben-
Disclaimer: I just work here!
Article: 102982If you sample the input signal with a GHz clock and use that to generate that clock to generate a delayed ouput you are going to have 1ns jitter in your delay, don't you Yes, it is true. But I woul like to implement oversampled method what means four times shifted 1GHz (500MHz) clock signal. then error will be 250 ps.Article: 102983
Antti wrote: > > it looks like I may up sinking more time into this by remaking the > damaged .ise files :( > If you haven't already spotted them, here's a few things that can help with the #$%&^! .ise file problems: - there's a tcl script mentioned in Answer Record 21067 that converts from .ise <-> ASCII dump - try using the .ise_ISE_Backup file when the .ise has been corrupted - for the registry key to edit to prevent opening last project, see : Answer Record: 20892 8.1i ISE - Project Navigator hangs at startup and project does not open BrianArticle: 102984
We will also have a V4 FX12 module for this board in design shortly that will be capable of higher clock rates and hence resolution. Hollybush1 can take an add on module with up to something like 110 I/O connecting to the Spartan-3 available I see this board with Spartan 3 and I think that with this board are possiable problems with jitter. Do you have any jitter measurment on Spartan 3 I/O pins, that you arrived on connectors.Article: 102985
thanks Brian! FYI, on of my last trips to US in a big book store there was one book thicker then the others. That one book had a proude title: "Surviving Windows 95 Registry" I hope Xilinx can fix the issues without the need of the book called "Surviving WinXP Registry Vol IV" But thanks, I actually do manage with the registry, even without that damn book, if I know that something is fixable AnttiArticle: 102986
johnp schrieb:
> Dennis -
> Can you post some of the code you use to generate the frame_ready
> signal? I suspect you've got a problem in how you pass the signal
> from one clock domain to the other, but without seeing some code
> it's hard to guess what's going on.
>
> John Providenza
Hello,
sorry for my late response, but I was not in the office for 2 days.
Here the synchronization follows:
--Frame rdy counter to enlarge frame_rdy_125 (@125MHz RX-CLK)
process(rxclk_in,rst_in)
begin
if (rst_in='1') then
frame_rdy_count <= 0;
elsif rising_edge(rxclk_in) then
if (frame_rdy_125='1') then
frame_rdy_count <= 3;
else
if (frame_rdy_count>0) then
frame_rdy_count <= frame_rdy_count - 1;
end if;
end if;
end if;
end process;
frame_rdy_125_ext <= '1' when frame_rdy_count>0 else '0';
-- FRAME_RDY_OUT Generator (@100MHz)
process(clk_in,rst_in)
begin
if (rst_in='1') then
frame_rdy_125_d1 <= '0';
frame_rdy_125_d2 <= '0';
elsif rising_edge(clk_in) then
frame_rdy_125_d1 <= frame_rdy_125_ext;
frame_rdy_125_d2 <= frame_rdy_125_d1;
frame_rdy_125_d3 <= frame_rdy_125_d2;
end if;
end process;
frame_rdy_out <= frame_rdy_125_d2 and (not frame_rdy_125_d3);
I believe, that I made a mistake in how to handle the receiving-clock,
which
might be not clean enough to work properly.
Dennis
Article: 102987I don't understand where the there are issues of jitter unless you use a DCM in which case you will have issues with all Xilinx FPGAs and to varying extent other vendors too. The point of our board is that you can have a high speed clock with low jitter and not necessarily using the DCM which does have jitter of some 10s of picoseconds. If you have a look at a ICS8442 and it's spec that is the chip we use for our LVDS clock module. Utimately your clock source is highly important if jitter is the issue. Other factors like power supply and decoupling will be possibly an issue. What you may thinking about is either bond out flight time which does vary from pin to pin and more so on the Spartan-3 FG packages than the Flip-Chip packaged Virtex-4, Otherewise there may be an internal routing delay variation. The latter varies by usually small amounts but can be checked in tools. I believe flight time figures are available for the Spartan-3 but I don't have them with me at present. On trace lengths we do have I/O pairs of signals on Hollybush1 generally tracked to have match lengths to about 0.1mm variation. this is principally for LVDS operation but also useful for applications like yours. John Adair Enterpoint Ltd. - Home of Broaddown2. Spartan-3 board now with added V4. http://www.enterpoint.co.uk "amko" <sinebrate@yahoo.com> wrote in message news:1148470557.129979.191160@38g2000cwa.googlegroups.com... > We will also have a V4 FX12 module for this board in design shortly > that > will be capable of higher clock rates and hence resolution. Hollybush1 > can > take an add on module with up to something like 110 I/O connecting to > the > Spartan-3 available > > I see this board with Spartan 3 and I think that with this board are > possiable problems with jitter. > Do you have any jitter measurment on Spartan 3 I/O pins, that you > arrived on connectors. >Article: 102988
I am running WebPack ISE 8.i on Linux (Ubuntu). On every step of the flow I get the warning "WARNING: en is not supported as a language. Using usenglish.". How can I avoid it? Thanks, JoeArticle: 102989
Thanks, I TIG'ed those nets, but unfortunately some new ones in the FIFOs then had the same issue. I will have to figure out why ISE is confused. Cheers, Rob.Article: 102990
Hi, how does debug work in with fpga? On common processor you can move from line to line of code, check variables values and have the whole system control with the jtag. How do things change here? Thanks, MarcoArticle: 102991
rob.misc@gmail.com schrieb: > Thanks, I TIG'ed those nets, but unfortunately some new ones in the > FIFOs then had the same issue. I will have to figure out why ISE is > confused. It there somewhere an option to disable cross clock domian timing analysis? AFAIK there is such an option in Alteras Quartus-II Software. But ISE from Xilinx?? Regards FalkArticle: 102992
Marco schrieb: > Hi, > how does debug work in with fpga? > On common processor you can move from line to line of code, check > variables values and have the whole system control with the jtag. > How do things change here? You can do the same thing in the simulator. In the real system, such things are often not usefull, since the FPGA interacts in realtime with external components (RAM, busses, whatever). So you need some kind of real time debugging. Simples method is using some pins to access internal nodes and wathcing them using a scope or logic analyzer. More complex debugging can be done using an integrated logic analyzer, integrated into the FPGA fabric, accessible via JTAG or special interfaces. On think I do is to use a Picoblaze as a terminal server to access internal registers and nodes. Works nice. (But only for Xilinx) Regards FalkArticle: 102993
Falk, really interesting your idea of using a Picoblaze as a terminal server, I have to deal with a Spartan3, could you please give more details on the way you do that? Thanks, MarcoArticle: 102994
Hi Falk,
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message
news:4dj434F1avlqmU1@individual.net...
> rob.misc@gmail.com schrieb:
> > Thanks, I TIG'ed those nets, but unfortunately some new ones in the
> > FIFOs then had the same issue. I will have to figure out why ISE is
> > confused.
>
> It there somewhere an option to disable cross clock domian timing
> analysis? AFAIK there is such an option in Alteras Quartus-II Software.
> But ISE from Xilinx??
The Xilinx timing analyser only examines paths which are constrained, so the
problem here is (I think) that a spurious constraint has found its way into
the system. Usually the constraints are either user-entered or generated by
the synthesis tool (and then used as a guide by the subsequent mapping,
placement and routing stages).
XST has an option to ignore paths between different clock domains for
timing, and not create constraints based on its analysis of such paths.
In this case, the paths are within a FIFO module generated from Coregen. It
sounds to me like these constraints have been written out by coregen (into
the .ngc netlist, probably), when they're actually unnecessary. The
workaround is to TIG these paths manually; the solution is to get the IP
fixed so these spurious constraints are not propagated into the design in
the first place.
Cheers,
-Ben-
Article: 102995Marco schrieb: > Falk, > really interesting your idea of using a Picoblaze as a terminal server, > I have to deal with a Spartan3, could you please give more details on > the way you do that? Its straight forward. Use a Picoblaze from xapp213. There is a version for Spartan-II (4K BRAMs) and Spartan3 (18k BRAMs). Just connect some registers to the IO bus. Also connect the UART from xapp?? (233?). Connect the UART with your PC (level converters necessary, of cource). Use hyperterminal or whatever you like to send char down to the FPGA. Now all you need is a small program inside the picoblaze that waits for the reception of a special char from the UART, lets say 'd' like debug. Then a routine can do whatever you like, do a register dump, set some registers, the possibilities are endless. Regards FalkArticle: 102996
Falk, I think I'll try that and, if I'll fail somewhere, I'll ask you for more help. Thanks again, MarcoArticle: 102997
Hi Brad, > And are there any free examples of VHDL that will drive slave devices. I > have found an ap note Xapp172 Design of Video Capture but I can't find the > source code downloads. I have pasted some code below, hope this helps. We have used this code to control audio volumes of Crystal DACs. The module takes volume data from the outside world and sends them to the DAC via I2C. Should be easy to adapt. I believe this is way easier than using PicoBlaze for the task. In case you need the file (due to line break problems, whatever), drop me a line. Best regards, Felix -- Dipl.-Ing. Felix Bertram http://www.bertram-family.com/felix -------------------------------------------------------------------------------- -- File: i2c.vhd -- Description: Simple I2C controller. -- History: Felix Bertram, 2002jan11, Created. -------------------------------------------------------------------------------- library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity ValI2C is port ( -- clocks & reset clk24: in std_logic; reset: in std_logic; -- dynamic data from external units (token wrd) val: in std_logic_vector(7 downto 0); -- value idx: out std_logic_vector(7 downto 0); -- index -- i2c bus sda: out std_logic; scl: out std_logic ); end ValI2C; -------------------------------------------------------------------------------- architecture bhv of ValI2C is ------------------------------------ -- basic structure -- note: data field is used for constants or value-indices type i2cE is (start, stop, const, wrd); type i2cT is record tag: i2cE; data: std_logic_vector(7 downto 0); end record; ------------------------------------ -- Crystal CS43L43 control sequence -- i2c start condition -- i2c address= 001000, R/nW= 0 -- memory address pointer -- volume data -- i2c stop condition type seqT is array(0 to 9) of i2cT; constant seq: seqT:= ( (start, x"00"), (const, "0010000" & '0'), (const, x"04"), -- 04h Channel A Digital Volume Control (wrd, x"00"), (stop, x"00"), -- (start, x"00"), (const, "0010000" & '0'), (const, x"05"), -- 05h Channel B Digital Volume Control (wrd, x"00"), (stop, x"00") ); ------------------------------------ -- clock divider and sequencing signal idxSeq: integer range seqT'low to seqT'high; signal idxBit: unsigned(3 downto 0); signal idxCyc: unsigned(1 downto 0); signal clkdiv: unsigned(8 downto 0); signal clkp1a, clkp1b: std_logic; signal clken: std_logic; ------------------------------------ -- transmit data signal txd: std_logic_vector(8 downto 0); constant txdstart: std_logic_vector(8 downto 0):= "111000000"; -- I2C start pattern constant txdstop: std_logic_vector(8 downto 0):= "000000111"; -- I2C stop pattern begin -- ic2 clock divider, approx 100kHz process(clk24, reset) begin if reset= '1' then clkdiv<= (others=> '0'); clkp1b<= '0'; elsif rising_edge(clk24) then clkdiv<= clkdiv + 1; clkp1b<= clkp1a; end if; end process; clkp1a<= clkdiv(clkdiv'left); clken <= clkp1a and not clkp1b; ---------------------------------------------------------------------------- -- create i2c timing ---------------------------------------------------------------------------- -- i2c clock cycle counter: 4 cycles per bit -- |___ _______________ ________ -- sda |___X_______________X________ -- | _______ ____ -- scl |_______/ \_______/ -- | -- phase | 0 / 1 / 2 / 3 / 0 / 1 / 2 / ... process(clk24, reset) begin if reset= '1' then idxCyc<= "00"; elsif rising_edge(clk24) then if clken= '1' then if idxCyc/= "11" then idxCyc<= idxCyc + 1; else idxCyc<= "00"; end if; end if; end if; end process; -- i2c bit counter: 9 bits per token (8 data + 1 ack) process(clk24, reset) begin if reset= '1' then idxBit<= x"8"; elsif rising_edge(clk24) then if clken= '1' and idxCyc= 3 then if idxBit/= x"8" then idxBit<= idxBit + 1; else idxBit<= x"0"; end if; end if; end if; end process; -- i2c sequence counter: see seqT definition process(clk24, reset) begin if reset= '1' then idxSeq<= seqT'high; elsif rising_edge(clk24) then if clken= '1' and idxCyc= 3 and idxBit= 8 then if idxSeq/= seqT'high then idxSeq<= idxSeq + 1; else idxSeq<= 0; end if; end if; end if; end process; ---------------------------------------------------------------------------- -- create i2c clock and data ---------------------------------------------------------------------------- -- create data address idx<= seq(idxSeq).data; -- select byte to transfer, send out bits msb first process(clk24, reset) begin if reset= '1' then txd<= (others=> '1'); elsif rising_edge(clk24) then if clken= '1' and idxCyc= 0 then if idxBit= 0 then case seq(idxSeq).tag is when start => txd<= txdstart; when stop => txd<= txdstop; when const => txd<= seq(idxSeq).data & '1'; -- const + ack when wrd => txd<= val & '1'; -- value + ack end case; else txd<= txd(7 downto 0) & '-'; end if; end if; end if; end process; sda<= txd(8); -- select clock to transfer, send out clock process(clk24, reset) begin if reset= '1' then scl<= '1'; elsif rising_edge(clk24) then if clken= '1' then case seq(idxSeq).tag is when const | wrd=> scl<= idxCyc(0) xor idxCyc(1); when start=> scl<= not(idxBit(3) or idxBit(2)); when stop=> scl<= idxBit(3) or idxBit(2); end case; end if; end if; end process; end bhv; -------------------------------------------------------------------------------- -- end of fileArticle: 102998
Dennis - Note that you create frame_rdy_125_ext <= '1' when frame_rdy_count>0 else '0'; as an combinatorial signal. Thus it may have decode glitches on it as the counter outputs change. These glitches could be caught by the 100MHz clock. Try making frame_rdy_125_ext synchronous. A simpler approach that does not require a counter is to simply toggle frame_rdy_125_ext each time a new frame is ready. In the 100MHz domain, synchronize the signal, then look for an edge to indicate a new frame: frame_rdy_out <= frame_rdy_125_d2 != frame_rdy_125_d3; Good luck! John ProvidenzaArticle: 102999
Since that I should add still LVDS/ECL or LVDS/NIM converters/drivers what will results in additional jitter. Can you guarantee that jitter on your LVDS (high speed links) is less than 50ps. What about external trigger uncertainly domain. For this case I probably need very accurate input comparator. Spartan 3 DCM period Jitter is +/150ps.
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