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
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag news:43b42229$0$11352$3b214f66@tunews.univie.ac.at... > Anyone an idea about the availability and pricing of their > starter kit. The new Fusion line looks very interesting. > Almost all needed stuff on-chip - I'm only missing some > larger SRAM for microprocessor applications. > > Martin > 399 EUR, I already ordered it anttiArticle: 93751
"John_H" <johnhandwork@mail.com> schrieb im Newsbeitrag news:quVsf.9875$Q73.8799@trnddc03... > Alex Gibson wrote: >> According to the front page of xilinx's site but not yet in the web shop. >> >> http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-SPAR3E-DK >> >> With double the amounts of ram and flash than origonally announced. >> >> Now if only xilinx sold digilentincs addon cards >> so could get some decent shipping charges. >> >> Alex > > It's been front-(wb)page news for 2 days and it's *still* not at the > online store. If it's available, what's the proper way to get hold of > one? Do I need to contact my local sales guy for a development board? > > We're a big account but I don't want to bother with a PO in this "belt > tightening" era so I'll just buy the darned thing myself and use it at > work and home. Best way to do this is the online store. Where else > *should* I go? strange, when I registered the 25USD off from the Spartan3e starterkit price I was provided to online order link directly, but I cancelled out. but it looked like the online ordering was available AnttiArticle: 93752
"Antti Lukats" <antti@openchip.org> wrote in message news:dp15b4$ocs$00$1@news.t-online.com... > are commercial with no demo no eval and whats even worse only in japanese > Hi Antti, So the Google taskbar gives you a 'transrate into Engrish feature' when you right click on the web page. I translated the first couple of paragraphs for you below. What you say? Spartan3E Sample Pack The variety you knew concerning the board which with the ET2005 was distributed with pulling out selection. First, name of this board seems that, " Spartan3E Sample Pack ". As for this, it probably is the place such as the kind of board which is located between the Spartan3E Starter Kit where sale is planned in the Spartan3 Starter Kit of the example which is sold before and December of 2005. HTH, Cheers, Syms. ;-)Article: 93753
"Symon" <symon_brewer@hotmail.com> schrieb im Newsbeitrag news:43b429bf$0$15786$14726298@news.sunsite.dk... > "Antti Lukats" <antti@openchip.org> wrote in message > news:dp15b4$ocs$00$1@news.t-online.com... >> are commercial with no demo no eval and whats even worse only in japanese >> > Hi Antti, > So the Google taskbar gives you a 'transrate into Engrish feature' when > you right click on the web page. I translated the first couple of > paragraphs for you below. What you say? > Spartan3E Sample Pack > The variety you knew concerning the board which with the ET2005 was > distributed with pulling out selection. > > First, name of this board seems that, " Spartan3E Sample Pack ". As for > this, it probably is the place such as the kind of board which is located > between the Spartan3E Starter Kit where sale is planned in the Spartan3 > Starter Kit of the example which is sold before and December of 2005. > > > > HTH, Cheers, Syms. ;-) > > Hi Syms, as I understand the free sample packs are to be distributed during january so that the 25OFF discount offer would still be valid. the japanese reading was really funny after translation :) the LTC dual 3by3mm switching supply is really cool, and the LTC6905 too well there is a mistake in the datasheet supplied with sample pack CD, it refers the resistor set version, but the board itself is fitted with fixd 50MHz actual measurement result was about 0.5% of from 50MHz on my board. AnttiArticle: 93754
Dear Group,
I know how annoying it is when one posts blocks of HDL, but I would
really appreciate someone telling me why this code does not work -- or
at least, a pointer to my stupidity!!!
This HDL is supposed to generate standard -ve syncs plus an early
'newline' signal to a specialised SDRAM controller which writes a
complete line of octets into alternate block-RAMs in my Spartan-3
device.
It then attempts to display them by generating alternate read enables
(based on the current vertical line).
Tomorrow I am going to rewrite the code using discrete processes (one
for each sync signal etc...).
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
use IEEE.numeric_std.all;
entity VidCont is
generic(
DATA_WIDTH : natural := 16; -- video data width
VADDR_WIDTH : natural := 10 -- Video FIFO
(blockRAM) address width
);
port(
-- Interface
clk : in std_logic; -- Master clock @25MHz
rst : in std_logic; -- Reset
-- Video blockRAM side
VIAddr : out std_logic_vector(VADDR_WIDTH-1 downto 0);
-- Video line buffer address
VADIn : in std_logic_vector(DATA_WIDTH-1 downto 0);
-- Data from 'A' block RAM
VEnA : out std_logic; -- Enable 'A' FIFO
VBDIn : in std_logic_vector(DATA_WIDTH-1 downto 0);
-- Data from 'B' block RAM
VEnB : out std_logic; -- Enable 'B' FIFO
NewLine : out std_logic; -- Initiate line read burst
-- TFT interface
VRed : out std_logic_vector(5 downto 0); -- 6-bit
red
VGreen : out std_logic_vector(5 downto 0); -- 6-bit
green
VBlue : out std_logic_Vector(5 downto 0); -- 6-bit
blue
VDE : out std_logic; -- Data-enable
VVSync : out std_logic; -- Vertical synch.
VHSync : out std_logic; -- Horizontal synch.
-- Debug signal...
Debug : out std_logic
);
end VidCont;
architecture arch of VidCont is
constant YES : std_logic := '1';
constant NO : std_logic := '0';
constant HI : std_logic := '1';
constant LO : std_logic := '0';
constant ONE : std_logic := '1';
constant ZERO : std_logic := '0';
-- TFT timing parameters...
constant tHP : natural := 800; -- Horizontal sync. period
constant tWH : natural := 96; -- Horizontal sync. width
constant tVP : natural := 525; -- Vertical sync. period
constant tWV : natural := 2; -- Vertical sync. width
constant tHV : natural := 640; -- Active horizontal period
constant tHBP : natural := tWH+40; -- End of H back porch (start
of active area)
constant tHFP : natural := tHBP+tHV; -- Start of H front porch (end
of active area)
constant tVV : natural := 480; -- Active vertical period
constant tVBP : natural := tWV+33; -- End of V back porch (start
of active area)
constant tVFP : natural := tVBP+tVV; -- Start of V front porch (end
of active area)
-- Horizontal & vertical counters...
signal hCount_x, hCount_r : natural range 0 to tHP+1;
-- Horizontal column count
signal vCount_x, vCount_r : natural range 0 to tVP+1;
-- Address counters...
signal hAddr_x, hAddr_r :
std_logic_vector(VIAddr'range); -- Horizontal address
-- Data enable flags...
signal hDEm3_x, hDEm3_r : std_logic; -- Early (-3)
horizontal data enable
signal hDEm2_r : std_logic; -- Early (-2)
latched horizontal data enable
signal hDEm1_r : std_logic; -- Early (-1)
latched horizontal data enable
signal hDE_r : std_logic; -- Horizontal
data enable
signal vDEm2_x, vDEm2_r : std_logic; -- Early (-2)
vertical data enable
signal vDEm1_r : std_logic; -- Early (-1)
vertical data enable
signal vDE_r : std_logic; -- Vertical
data enable
signal nlBurst_x, nlBurst_r : std_logic; -- Newline
burst strobe
signal IVEnA_x, IVEnA_r : std_logic; -- Block RAM
'A' read enable
signal IVEnB_x, IVEnB_r : std_logic; -- Block RAM
'B' read enable
-- Syncs...
signal IVSync_x, IVSync_r : std_logic; -- Vertical
sync
signal IHSync_x, IHSync_r : std_logic; -- Horizontal
sync
signal AltLine_x, AltLine_r : std_logic; -- Source
flipper
-- RGB data...
signal RGB_x, RGB_r :
std_logic_vector(VADIn'range); -- Demultiplexed and latched RGB data
begin
-- Attach signals to outputs...
VIAddr <= hAddr_r; -- Horizontal address = block RAM address
VDE <= hDE_r; -- Display enable...
VRed(5 downto 1) <= RGB_r(15 downto 11);
VRed(0) <= RGB_r(15);
VGreen(5 downto 0) <= RGB_r(10 downto 5);
VBlue(5 downto 1) <= RGB_r(4 downto 0);
VBlue(0) <= RGB_r(4);
VHSync <= IHSync_r;
VVSync <= IVSync_r;
VEnA <= IVEnA_r;
VEnB <= IVEnB_r;
NewLine <= nlBurst_r;
Debug <= IHSync_r;
-- Determine next state...
RGB_x <= VBDIn when AltLine_r = '0' else VADIn; -- Video input mux
IHSync_x <= LO when hCount_r = (tHP-1) else HI when hCount_r =
(tWH-1) else IHSync_r; -- Hor. sync generation
IVSync_x <= LO when vCount_r = (tVP-1) else HI when vCount_r =
(tWV-1) else IVSync_r; -- Vert. sync generation
hCount_x <= 0 when hCount_r = (tHP-1) else hCount_r + 1; -- Hor.
counter
vCount_x <= 0 when vCount_r = (tVP-1) else vCount_r + 1 when hCount_r
= (tHP-1) else vCount_r; -- Vert. counter
AltLine_x <= LO when vCount_r = (tVP-1) else not AltLine_r when
hCount_r = (tHP-1) else AltLine_r; -- Alternate line generation
hDEm3_x <= HI when (hCount_r = (tHBP-1)) and (vDEm2_r = HI) else LO
when hCount_r = (tHFP-1) else hDEm3_r; -- Early horizontal DE
vDEm2_x <= HI when vCount_r = (tVBP-1) else LO when vCount_r =
(tVFP-1) else vDEm2_r; -- Early vertical DE
nlBurst_x <= HI when (vDEm1_r = '1') and (hCount_r = (tWH-1)) else
LO; -- BlockRAM fill strobe
hAddr_x <= hAddr_r + 1 when hDEm2_r = '1' else (others => '0'); --
Keep advancing blockRAM address during active window, else reset
IVEnA_x <= HI when AltLine_r = '1' else LO;
IVEnB_x <= HI when AltLine_r = '0' else LO;
update : process(rst, clk)
begin
if rst=YES then
-- Asynchronous reset...
hAddr_r <= (others => '0');
hDEm3_r <= '0';
hDEm2_r <= '0';
hDEm1_r <= '0';
hDE_r <= '0';
vDEm1_r <= '0';
vDEm2_r <= '0';
vDE_r <= '0';
nlBurst_r <= '0';
IVEnA_r <= '0';
IVEnB_r <= '0';
IVSync_r <= '1';
IHSync_r <= '1';
hCount_r <= 0;
vCount_r <= 0;
AltLine_r <= '0';
RGB_r <= (others => '0');
-- elsif rising_edge(clk) then
elsif clk'event and clk='1' then
-- Ripple pipline display enable bits...
hDEm3_r <= hDEm3_x;
hDEm2_r <= hDEm3_r;
hDEm1_r <= hDEm2_r;
hDE_r <= hDEm1_r;
vDEm2_r <= vDEm2_x;
vDEm1_r <= vDEm2_r;
vDE_r <= vDEm1_r;
nlBurst_r <= nlBurst_x;
IVEnA_r <= IVEnA_x;
IVEnB_r <= IVEnB_x;
-- Syncs...
IHSync_r <= IHSync_x;
IVSync_r <= IVSync_x;
-- Video data/address...
hAddr_r <= hAddr_x; -- Update video RAM address
RGB_r <= RGB_x; -- Latch video data
-- Counters...
hCount_r <= hCount_x;
vCount_r <= vCount_x;
AltLine_r <= AltLine_x;
end if;
end process update;
end arch;
Thanks for your patience.
Regards,
Peter
Article: 93755I would like to capture an display video images using a Xilinx ML402 development kit. I am looking for advice about how to proceed. I have the datasheet for the Infineon HYB25D256 DRAM and I also found XAPP608 that describes DRAM control for a Micron DRAM module. I also noticed that the Platform Studio has a DRAM controller. I am not sure that I want to get into Platform Studio or deal with OPB busses however. At first, the DRAM controller need only write data from a camera and read data to the VGA display. At different clock frequencies so FIFOs will be needed I suppose. Can any one point me in the right direction? Brad Smallridge aivision.comArticle: 93756
> Martin Schoeberl wrote: >> However, it's not so important - just a little bit of marketing >> stuff ;-) > > No, Martin, it is not Marketing, it is Science. Let's say inbetween. The description of the method in the Xilinx paper is not self contained. And the initial criticism still holds: Where are the numbers at 25C? About scientific relevant measurements: How many different FPGAs (from different production runs) have been measured for this paper? > Dynamic power and static power (leakage) have different temperature > dependencies: > Dynamic power is independent of temperature (since the frequency and > the capacitance do not change), while leakage current is very > temperature dependent. > The two can be added linearily. > Therefore it is not necessary to measure dynamic power at temperature. Ok, thanks for the clarification. But in this paper the overall power was measured at 25C and the static power was added from some other source for the 85C figure. > > And let this quibbling not obfuscate the basic fact: > Xilinx power consumption is much lower than Altera's. Didn't want to say that this is not correct, just a few thoughts about methods in the Xilinx paper. MartinArticle: 93757
Hi, I am working on a Virtex4 FX design, when the system clock runs at 100MHz, the memory controller core does not work correctly. Then I inserted ChipScope trying to identify the problem, but once it is inserted, the problem is gone! I know it is of timing problem since if I lower the system clock to 50MHz, there is no problem either. It looks like that after the chipscope is inserted, somehow the routing is altered in favor of the memory controller. I just wonder if there are any trick so that Chipscope insertion does not impact design routing?Article: 93758
Martin Schoeberl wrote: > > Ok, thanks for the clarification. But in this paper the > overall power was measured at 25C and the static power was > added from some other source for the 85C figure. > Martin, I find it hard to be patient with you. If dynamic power is constant with temperature, and static power increases monotonically with temperature, and total power is always the linear sum of static and dynamic power, then I can scientifically state that Total Power @85 = static power @85 + dynamic power @25 degrees. And that is not Marketing. (Which we all agree is almost a dirty word in our circles). Happy New Year ! Peter Alfke, Xilinx ApplicationsArticle: 93759
Lets discuss the brute force examination of a PAL16R8, for example, with absolutely no knowledge of its function. Lets assume a 16R8. Could we just clear all the inputs and toggle the clock line a few times and wait for a known output (that is, if there are any of the clocked feedback signals used, get them to the same state) and then on the next clock state try a new input? So... Refresh the PAL to a known state, try value $01, try $01 Refresh the PAL to a known state, try value $01, try $02 Refresh the PAL to a known state, try value $01, try $03 Until we get a truth table with 65,535 results. Can anyone help me think of a situation where this would NOT work? I suppose the next "problem" would be reducing and deciphering the equation. Lets assume there are no GALs being tested, only a 16R8.Article: 93760
Hi everyone, Is there any way for me to start a project on Virtex2Pro utilizing the PPC405 core using ONLY ISE (i.e. without EDK)? How do we instantiate the core in VHDL? I'm not really keen on using the EDK: (1) Too many 'black-box-wizards' - I'd like to know what connections are made and how it is connected. (2) Sometimes when I made some changes to my custom peripheral, the whole system becomes not usable - you know, the frustration of waiting for it to rebuild the system only to find it doesn't work AT ALL! Ooh.. by the way, I'm using the ML310 development board (XC2VP30). Thanks. -Azman-Article: 93761
Hi all, Thanks for your discussion. I figured so much that we cannot be using the bidirectional buses all over the program. but i for sure have my doubts on whether the IP core is 100%proper even just as an individual unit. The reason is after the address match where the I2C controller is addressed as slave it does not send the acknowledge bit. I have enabled both the options in the control register and checked it but to no avail. regards vasu Antti Lukats wrote: > <wtxwtx@gmail.com> schrieb im Newsbeitrag > news:1135599779.396787.40140@g14g2000cwa.googlegroups.com... > > Hi Antti, > > Thank you for indicating my wrong answer. > > > > I misunderstood the problem. > > > > One of errors is multi-source data_bus(7 downto 0) are assigned in more > > than one processes! > > > > It is easy to correct it: > > Use search key to search signal 'data_bus' through the module source > > file and see how many times the data_bus are assigned. Put all > > assignments in one process only. > > > > Weng > > > Weng you are a bit mistaken again the data_bus is assigned once outside > process > > data_bus <= data_out when (r_w = '1' and dtack_oe = '1') else (others => > 'Z'); > > in the uc_interface.vhd > > so the ip-core is 100% proper for its intended function - controller for > external microcontroller. > > for on-chip soc bus, the uc_interface module should be replaced, or > modified. > > anttiArticle: 93762
wtxwtx@gmail.com wrote: > Hi Robert, > Thank you for your excellent advice. > > Here are you key points: > 1. Read at least a dozen "closely" relate patents; > 2. You must describe the novel items; > 3. The claims should cover all possible aspects that can be legally > covered. > > I think this is inventor's responsibility: > looking at the item upside-down, sideways, backwards, inside-out, and > crazy-blue-sky if one can. > The example of paper clip doesn't exist for eletronical circuits. > > For eletronical circuit, the inventor must have to think a lot about > any possible designs around patents that any lawyers couldn't do it. > Block them or invent them together. > > I don't understand the following statement: > even as a "small entity" it is expensive. > > Thank you. > > Weng > The paper clip example was just an example and not intended to relate to chemical patents, boilogical patents, electronic patents or any specific type or class of patents. It was intended to only show that some un-thought-of aspect can be missed. Look at the charges; a "small entity" pays thousands of dollars - especially when one adds in the maintenance fees. Patents are as good and as bad as a copyright. All they do is give the holder incontestable proof that they are the owner, period. The size of the owner's wallet is more important when court action is deemed necessary. Only the rich win. See what Don Lancaster has to say about patents. Now you can do all of the research, write the the patent including well-crafted claime, and then post it on the web thereby putting it into the public domain. That means that any art derived from the patent is mostly PD itself, unless something "novel" is added - and only *that something* could be patented by that inventer. If your patent is something relatively fundamental (maser) then all new art based on that patent would theoretically be PD (if i understand the general drift of patent law correctly). I have written up a few patents and put them on the web. A hell of a lot cheaper and my wallet does not have to be invaded in defending poachers.Article: 93763
"king_azman" <azman@kukum.edu.my> schrieb im Newsbeitrag news:1135921493.585548.260440@z14g2000cwz.googlegroups.com... > Hi everyone, > > Is there any way for me to start a project on Virtex2Pro utilizing the > PPC405 core using ONLY ISE (i.e. without EDK)? How do we instantiate > the core in VHDL? > > I'm not really keen on using the EDK: (1) Too many 'black-box-wizards' > - I'd like to know what connections are made and how it is connected. > (2) Sometimes when I made some changes to my custom peripheral, the > whole system becomes not usable - you know, the frustration of waiting > for it to rebuild the system only to find it doesn't work AT ALL! > > Ooh.. by the way, I'm using the ML310 development board (XC2VP30). > > Thanks. > > -Azman- > there seems to be no example for really direct use of the PPC without edk, to get started study the XAPP807 sources carefully it may help to get you started. what I found reayll cool is the way the XAPP807 uses the User Access register to implement a bitstream "bridge" to the PPC405 internal JTAG register todo the PPC cache loading from the config bitstreamArticle: 93764
HI, guy, because you use that clock whcih are generated by combinatorial logic, you must use the CLOCK_SIGNAL constrait to specify that clock singal; if so, you can use that clock in the process. jasonArticle: 93765
On 29 Dec 2005 17:13:42 -0800, "logjam" <grant@cmosxray.com> wrote: >Lets discuss the brute force examination of a PAL16R8, for example, >with absolutely no knowledge of its function. > >Lets assume a 16R8. > >Could we just clear all the inputs and toggle the clock line a few >times and wait for a known output (that is, if there are any of the >clocked feedback signals used, get them to the same state) and then on >the next clock state try a new input? > >So... >Refresh the PAL to a known state, try value $01, try $01 >Refresh the PAL to a known state, try value $01, try $02 >Refresh the PAL to a known state, try value $01, try $03 > >Until we get a truth table with 65,535 results. > >Can anyone help me think of a situation where this would NOT work? > >I suppose the next "problem" would be reducing and deciphering the >equation. > >Lets assume there are no GALs being tested, only a 16R8. This ought to work for a 16R8, assuming you have a way to refresh to a known state (can't remember if the register load function works after the security fuse is blown) The 16R8 is probably about the simplest as you don't have tri-stated outputs or combinatorial outputs to think about. As soon as you move to a GAL the permutations rise dramatically....Article: 93766
Good question! A friend and I had a discussion about a situation like that once. A PAL16R8 is really quite a simple piece of logic compared to what is available today or even it's cousin the GAL16V8. I say "simple" even though it is a 16R because is has 8 inputs and 8 outputs. The "tricky" part of course is that there is a possibility that the flip-flop on each output pin might be directed back in to the Array, or fuse map as it is sometimes called. When my friend and I discussed this "directed back in to the Array " possibility he had stated that it might be near impossible due to the fact that no one could be sure how many flip-flops were wired to go back in to the Array. Could be none, could be all. I then thought about this and concluded that it would be near impossible to design something useful that could possibly use ALL the flip-flops in the chip at once and direct the back in to the Array, being that there is only one Clock pin and one Output Enable pin, or so I believe. *** Maybe some one can expand on this possibility further? *** As far as I can tell from a design standpoint there are so many flip-flops to be used either as Latches or for design convenience. I say "convenience" because it may be hard to wire up the flip-flop if it were on the "top" of the Array (say Row 0) and you needed it at the bottom (say Row 2016). Or at least this is what I have come to believe and I am by no means what I would consider a PAL design expert. I think these PLD's are great for something from the 1980's like addressing RAM, but have little if any use today, hence the GAL. Now as far as trying to decipher how the PAL is programmed would be a bit of a mystery to me as I'm not a Math major. I would start by using a Data Acquisition Unit (DAQ for short) like this one by Datx: http://www.datx.com/econ/prod_dt9817.htm. Here are some neat features of the device. #1 The Software. Most important of all is the software. You'll need to be able to write your own code and try and formulate a program to send and log test signal results. #2 Digital I/Os (DIO). The unit has 28 DIOs! Plenty for testing any PAL16. #3 Price. The unit is only $180! Not a bad deal really. #4 Power. The thing I like best about this box is that it is USB and will supply it's own 5v power for the IC. No extra power supply is needed. Cool idea eh? ;) Now the hard part. Make friend with the smartest Math kid you can find and promise him women, lots of them if he can write a program to send an input to each pin of the PAL and log the results. With time and enough results you should then be able to write a program to formulate a logic equation of what the PAL is doing. Sounds easy, but it's not. Then once you have some idea of the logic possibilities then recreate the PAL in a GAL16V8 and try your design in the circuit you removed the PAL from. If it works, you'll need to find those women for you new buddy. If it doesn't then I'd make a new Math friend. ;) Now does any body know if there is a prewritten program that might help in analyzing the results from the DAQ? I imagine there must be something. I don't have enough Math background but maybe someone in this group could express the PAL16R8 as a mathematical equation? I'd love to see that! Post again and let us know how things are going. I'd like to see the program you have written when your done. Henry "logjam" <grant@cmosxray.com> wrote in message news:1135905222.916789.165390@g14g2000cwa.googlegroups.com... > Lets discuss the brute force examination of a PAL16R8, for example, > with absolutely no knowledge of its function. > > Lets assume a 16R8. > > Could we just clear all the inputs and toggle the clock line a few > times and wait for a known output (that is, if there are any of the > clocked feedback signals used, get them to the same state) and then on > the next clock state try a new input? > > So... > Refresh the PAL to a known state, try value $01, try $01 > Refresh the PAL to a known state, try value $01, try $02 > Refresh the PAL to a known state, try value $01, try $03 > > Until we get a truth table with 65,535 results. > > Can anyone help me think of a situation where this would NOT work? > > I suppose the next "problem" would be reducing and deciphering the > equation. > > Lets assume there are no GALs being tested, only a 16R8. >Article: 93767
"Henry" <apl2research@comcast.net> schrieb im Newsbeitrag news:XKydnZQtkMWSkCjenZ2dnUVZ_sqdnZ2d@comcast.com... > Good question! A friend and I had a discussion about a situation like > that once. A PAL16R8 is really quite a simple piece of logic compared to > what is available today or even it's cousin the GAL16V8. I say "simple" > even though it is a 16R because is has 8 inputs and 8 outputs. The > "tricky" part of course is that there is a possibility that the flip-flop > on each output pin might be directed back in to the Array, or fuse map as > it is sometimes called. [snip] there are ABSOLUTLY no issues reversing the R8 NO PROBLEMS R8 has no output cells with internal tristate control meaning that all the FF outputs are always observable, meaning that FULL 100% guaranteed recovery of the fusemap is possible without any major issues anttiArticle: 93768
On a sunny day (29 Dec 2005 15:27:32 -0800) it happened "Peter Alfke" <peter@xilinx.com> wrote in <1135898851.959376.84950@o13g2000cwo.googlegroups.com>: > >Martin Schoeberl wrote: >> > Ok, thanks for the clarification. But in this paper the >> overall power was measured at 25C and the static power was >> added from some other source for the 85C figure. >> >Martin, I find it hard to be patient with you. >If dynamic power is constant with temperature, >and static power increases monotonically with temperature, >and total power is always the linear sum of static and dynamic power, >then I can scientifically state that > >Total Power @85 = static power @85 + dynamic power @25 degrees. > >And that is not Marketing. (Which we all agree is almost a dirty word >in our circles). > >Happy New Year ! >Peter Alfke, Xilinx Applications > You should publish true measured values, or just give the fomula. This is normal practice.Article: 93769
Hi Peter, It would appear from your VHDL code that you're sending sync signals out of your entity that are generated from combinational logic. I would suggest that this is BAD. Look at this line:- IHSync_x <= LO when hCount_r = (tHP-1) else HI when hCount_r = (tWH-1) else IHSync_r; -- Hor. sync generation The signal IHSync_x is the signal that gets propagated out of the design. The problem is that not all of the wires that make up signal hCount_r change at exactly the same time. There will be some skew on them. This means that IHSync_x could have glitches on it. Not good for a sync signal! Move the VHDL line inside the clocked update process. That way, IHSync_x will come straight from a FF and will be glitch free. HTH, Syms. p.s. I hope the wine is still flowing in Greece? Wish I was there myself, it's p-ing down here in Plymouth.Article: 93770
hii i have to study TCL SCRIPTING and i have to verify the VHDL codes, i have learnt this lannguage but have to verify the vhdl code using TCL SCRIPT. can any one out here please tell me how to go about. Any link or pdf doc. that explains how to do the same. suppose i have to verify a counter. i have to force values to teh signal, get it on the waveform. the entire process that a testbench does, has to be performed in TCL SCRIPT... i hope query is well explained. thanks HAPPY NEW YEAR TO ALLArticle: 93771
Hi Robert, I checked USPTO and found you hold 5 patents. I like to listen to your advices, experiences and lessons all ears. Several things for me to file patents are: 1. The circuits must be novel, and it will be applied in the industry without doubt. For example, they must be dramatic advantages over current ones in one of following respects: speed, performance, saving power or saving logic. 2. The 'novel' circuit must have potential buyers to make money. 3. History will keep your invention as a record and the circuit can go into textbooks. But basically, making money is the most important factor to file a patent. WengArticle: 93772
Hi, 1. I2C IP is so simple that it will never fail, in my opinion. 2. You are a newbie in this respect, the chance you make a mistake is beyond 99%. 3. If I2C controller contained in the IP doesn't send the acknowledge bit, your design is fundamentally wrong. Can you imagine an IP fails to response with an acknowledge bit? You may post your code and I will help you ID the first error, not all errors. WengArticle: 93773
<wtxwtx@gmail.com> schrieb im Newsbeitrag news:1135948399.905295.18330@g14g2000cwa.googlegroups.com... > Hi, > 1. I2C IP is so simple that it will never fail, in my opinion. > simple things fail too, and too often > 2. You are a newbie in this respect, the chance you make a mistake is > beyond 99%. > NO, the chances for an total newbie to get things right are defently better than 1% > 3. If I2C controller contained in the IP doesn't send the acknowledge > bit, your design is fundamentally wrong. > > Can you imagine an IP fails to response with an acknowledge bit? > > You may post your code and I will help you ID the first error, not all > errors. > > Weng > The I2C core at opencores had been available for many years, still when I needed it I found a fundamental error in it. So similary the XAPP333 may have error in it as well -- Antti Lukats http://www.xilant.comArticle: 93774
wtxwtx@gmail.com wrote: > Hi, > 1. I2C IP is so simple that it will never fail, in my opinion. There are a well know errors with I2C, one way with half finished transmissions where on partner in the transmission keeps pulling SDA or SCL low. SMBus introduces timeouts into the protocoll, pure I2C may need to switch off the partner, pulling the bus low. Sometimes this has to be done with the supply line... -- 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