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
iglam wrote: > That's way cool. What process were you running? Were you using delay lines > and one shots to handshake? > > Bob ================== > > It was (I believe) p-channel MOS ( these were the early calculator days), and > the self-timing was done with capacitive delays. The device came in a 16-pin package. 4 Din, 4 Dout, clock and Busy on the input, clock and Ready on the output. Could be cascaded ad infinitum. PeterArticle: 31876
Hi !
How can I force tristate enable registers into IOBs (xilinx Spartan II)
?
The synthesis tool (XST) makes one register out of the following 16
registers. But I want 16 registers directly in the IOBs ! How can I code
this without using the IOBUFs in the VHDL code !
-- generate 16 tristate enable register
gen1: for i in 0 to 16-1 generate
process(clk, reset)
begin
if reset='1' then
ge_mem_oe_reg(i) <= '1';
elsif rising_edge(clk) then
ge_mem_oe_reg(i) <= ge_mem_oe;
end if;
end process;
end generate;
-- 16 tristate enable buffer
gen2: for i in 0 to 16-1 generate
GE_MEM_D(i) <= ge_mem_out_reg(i) when ge_mem_oe_reg(i)='0' else 'Z';
end generate;
Matthias
Article: 31877Hi, I seek some information (samples) about cooperation microcontroller(8031) and FPGA(4005XL) - (only Abel, because I have no VHDL Xilinx Compiler) on the XSBoard v1.2. Thank you, Tom P.S. Sorry for previous title of questionArticle: 31878
Matthias Fuchs schrieb: > > Hi ! > > How can I force tristate enable registers into IOBs (xilinx Spartan II) > ? > > The synthesis tool (XST) makes one register out of the following 16 > registers. But I want 16 registers directly in the IOBs ! How can I code > this without using the IOBUFs in the VHDL code ! > > -- generate 16 tristate enable register > gen1: for i in 0 to 16-1 generate > process(clk, reset) > begin > if reset='1' then > ge_mem_oe_reg(i) <= '1'; > elsif rising_edge(clk) then > ge_mem_oe_reg(i) <= ge_mem_oe; > end if; > end process; > end generate; > > -- 16 tristate enable buffer > gen2: for i in 0 to 16-1 generate > GE_MEM_D(i) <= ge_mem_out_reg(i) when ge_mem_oe_reg(i)='0' else 'Z'; > end generate; > Hmm, FPGA Express does the job right. -- MFG FalkArticle: 31879
"Austin Franklin" <austin@dar54kroom.com> writes: >> >The only people who need the bitstream are the people developing the back >> >end tools, NOT the design entry tools. >> >> I was once working on a project that would have needed to know >> some of the bits. Most of the design was static, but some constants >> had to be changed before the data was loaded. Xilinx will tell you >> where the LUT bits are, at least in the 4000 series. (So you know >> which bits to ignore when you read the data out again.) >> >> Mostly it was loading the values for ROM compiled into the design, >> in a systolic array where each chip had different values. >> There are probably other projects that need similar information. >Isn't that still back end tools though? Having the front end tools know the >bitstream wouldn't help this as far as I can tell. I mean after the back end tools. At the time the stream is loaded into the FPGA array the ROM data is modified. About the equivalent of patching an .EXE file after compiling and linking. -- glenArticle: 31880
Ben, I can't resist. the Virtex II 2V40 is less than ~$25 in quantities, and due to drop even less in the future (fg256). Not bad for four DCM's (DLL+DPS+DFS), four 18Kb block rams, four 18x18 multipliers, 512 LUTS, 512 FF's, and the commeasurate IO's. It is less expensive to place all of the clock management, mirroring, and deskew for a system (the heck with the logic!) on a 2V40 than to buy just one 'robo clock.' Sorry about needing 256 fingers and toes though. It is also avaliable in a cs144 (only 8 people's fingers and toes?) Austin Ben Franchuk wrote: > Peter Alfke wrote: > > The device came in a 16-pin package. 4 Din, 4 Dout, clock and Busy on the input, > > clock and Ready on the output. Could be cascaded ad infinitum. > > Ah! the good old days when you could count pins on ones fingers and toes. > Also what ever happened to LOW COST chips like $25 not $250 or $2,500. > Ben.Article: 31881
Did the layout folks cut masks out of rubilith with an exacto knife? I've never actually seen the stuff. Bob "Peter Alfke" <peter.alfke@xilinx.com> wrote in message news:3B1FAAC7.DB361E0F@xilinx.com... > > > iglam wrote: > > > That's way cool. What process were you running? Were you using delay lines > > and one shots to handshake? > > > > Bob > > ================== > > > > > It was (I believe) p-channel MOS ( these were the early calculator days), and > > the self-timing was done with capacitive delays. > > The device came in a 16-pin package. 4 Din, 4 Dout, clock and Busy on the input, > clock and Ready on the output. Could be cascaded ad infinitum. > > Peter >Article: 31882
Hi, As far as I know, the configuration pins become user I/O's after initialisation. You can't do anything with changing the mode pins after configuration. Are you really sure that the device is configured (check the MODE pin)? "Werner Dreher" <dreher@informatik.uni-tuebingen.de> schreef in bericht news:3B1E530D.1A348D65@informatik.uni-tuebingen.de... > hello world, > > I'm designing a board with a SpartanII. The FPGA should be > configured using slave parallel mode (with a microcontroller), > and I want to be able to do readback (also in slave parallel). > Up to this point all is clear. > > But after configuration and while no readback is in progress, > I want to use the pins D0...D7, _CS, _WRITE and BUSY as user > I/Os. I understand the data sheet in the way that this should > be possible: "These pins become user I/Os after > configuration unless the Slave Parallel port is retained." > But how to retain the slave parallel port, and how to _not_ > retain? > Should I change the mode pins after configuration to free > D0...? Are the mode pins sampled after configuration too? > (the data sheet says that M0,M1,M2 are sampled before > configuration when _INIT goes high after clearing the > configuration memory.) > Or are D0...D7 user I/Os after configuration when _CS is not > asserted? But how to use _CS as user I/O? > > I can't find any hints in the data sheet or appnotes. > Can anyone help me? > > Greetings > WernerArticle: 31883
"Austin Franklin" <austin@dar54kroom.com> wrote: > Technically, two back to back flops IS a FIFO. "Pointers" and "flags" > are not required to be a FIFO. I wrote: > By themselves, no. It takes some specific logic to make them behave as > a FIFO. Counters are one way of doing it, but there are certainly others. Austin wrote: > Why? Double buffering IS a FIFO. First-In-First-Out...that's what happens > when you double buffer. I would not call a single buffer a FIFO though. If you just chain two flops on a common clock, what you have is a two-bit shift register. I don't see how from a practical point of view this can be considered a FIFO in any meaningful sense. If it is, then I guess you'd consider a 74164 to be an eight-deep FIFO. With a "proper" FIFO, regardless of the maximum depth D, you can present some number of data items Ni<=D at the input, and read out some number of data items No<=Ni at the output, without having to choose different FIFO output signals depending on the values of Ni and No. With just you two flops on a common clock, if you put only one bit into the "FIFO", you have to use the output of the first flop as your data output, but if you put two bits into the "FIFO", you have to use the output of the second flop. This is NOT the behavior expected of a FIFO. If you add a counter and a multiplexer, you can turn it into a FIFO, which is what I said in my previously quoted comment. > FIFO is really a concept, more so than a specific implementation. If you talk to a hardware engineer, you're going to find that he or she has more expectations of a FIFO than simply the ordering. In particular, it is expected that a FIFO can contain a VARIABLE amount of data, from zero items up to the FIFO depth. Your two flops with no logic always contain a FIXED amount of data. If you add flags to the data, i.e., have two additional flops for flags in addition to two for data, you could argue that you've now made the "FIFO" contain a variable amount of data. But it still is the case that you can't get the read data from the same signal independent of the amount of data in the "FIFO", without adding yet more logic. And yet your extra flops for the data are in fact "flags", which you claimed were not needed.Article: 31884
> Hi, > I seek some information (samples) about cooperation microcontroller(8031) > and FPGA(4005XL) - (only Abel, because I have no VHDL Xilinx Compiler) > on the XSBoard v1.2. maybe http://www.triscend.com ? JanuszR. -- http://www.miriady.prv.plArticle: 31885
Of course, and you had to make sure that the red cut-out piece wordn't drop down somewhere elso... Later we checked larger circuits by crawling on the floor. Those were the days. Not necessarily better, though. Peter iglam wrote: > Did the layout folks cut masks out of rubilith with an exacto knife? > I've never actually seen the stuff. > > Bob > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message > news:3B1FAAC7.DB361E0F@xilinx.com... > > > > > > iglam wrote: > > > > > That's way cool. What process were you running? Were you using delay > lines > > > and one shots to handshake? > > > > > > Bob > > > > ================== > > > > > > > > It was (I believe) p-channel MOS ( these were the early calculator > days), and > > > the self-timing was done with capacitive delays. > > > > The device came in a 16-pin package. 4 Din, 4 Dout, clock and Busy on the > input, > > clock and Ready on the output. Could be cascaded ad infinitum. > > > > Peter > >Article: 31886
> you're going to find that he or she > has more expectations of a FIFO than simply the ordering. In particular, > it is expected that a FIFO can contain a VARIABLE amount of data, from > zero items up to the FIFO depth. Your two flops with no logic always > contain a FIXED amount of data. No, that isn't true. That's YOUR limited understanding. This is REALLY a simple concept. I don't understand why you want to argue about this, except for the sake of arguing. You really don't know that FIFO simply means FIRST IN FIRST OUT, and anything that provides that function IS a FIFO? No matter what the implementation is? I have NOT disputed that the "common" expectation of a FIFO is different than two flops, but that does NOT make two flops NOT a FIFO. This is just so simple, and arguing about it is just so foolish. A toilet paper tube and a golf ball can make a FIFO for Christ's sake! It does not seem you want to understand this, or you do understand it, and simply want to argue, so any further efforts on my part would be simply futile, and I really do have better things to do with my time than this.Article: 31887
Take a look at www.vmetro.com they have some adapters. Steven Sanders wrote: > > Hello, > > We want to plug our Xilinx PCI development board in our > compactPCI bacplane. Are there any passive form factor adapters > out there for this kind of 'wild' testing? > > Thanx in advance! > > Steven -- ---- Lars Erik Svendsen <Lars-Erik.Svendsen@chello.no> Phone: +47 22 30 30 03 (Home), +47 92 45 85 72 (Cell) HomePage: http://home.chello.no/~lsvendse/ ICQ: 33272974 -----BEGIN GEEK CODE BLOCK----- GCM/CC d- s++:- a- C+++(+)$ UL++++$ P++>++++ L++>++++ E--- W+++ N+(+++) !o !K w-- O M- !V PS !PE !Y PGP---(-) t 5 X+ R+>++ tv- b+>++ DI+(++) D-- G+>++ e++ h!>++ r% z? ------END GEEK CODE BLOCK------Article: 31888
Peter Alfke wrote: > Of course, and you had to make sure that the red cut-out piece wordn't drop down > somewhere elso... > Later we checked larger circuits by crawling on the floor. > Those were the days. Not necessarily better, though. > Peter Aha! Now I get it. The drive to ever smaller geometries was nothing to do with performance and everything to do with the ever increasing price of SV floor space as the designs got bigger combined with a not unreasonable desire to avoid the strange layouts caused by the presence of filing cabinets, water coolers, the boss's desk, having to continue through a door into the next room etc.Article: 31890
Allan Herriman wrote: > I know it's "trivial" but I found it quite hard to get the best results > from a particular VHDL synthesiser (Synplify) when I tested this. > > The best way to express it in VHDL seems to be to use a constant array > to specify the state transitions > ... > constant num_counts : integer := 8; > > type count_array is array (0 to num_counts - 1) of integer; > > constant next_count : count_array := ( > 1,6,3,0,7,4,5,2 > ); Shouldn't that work out to be a ROM that's three bits wide? 3 CLBs? -andyArticle: 31891
Oh dear....., Maybe one of you two would like a sauser of milk? Stop making your selfs look silly and go to the local libary and try reading some books. Just an observation! Cyber_spook_manArticle: 31892
Peter, > I can e-mail the description to anybody interested. > > Peter Alfke Yes please, pjc@cyberspook.freeserve.co.uk RegardsArticle: 31893
Rick Filipkiewicz wrote: > > (lots of snip) > Great posting Eric. It should appear somewhere on a DRAM FAQ but Rambus would > probably sue the FAQ hoster. In fact if I were you I would consider getting a lawyer > now & moving all your assets off-shore. > > An interesting side note: When this came up I went I downloaded a RDRAM data sheet. > What did I see on the Rambus home page ? A little picture with a hot spot marked > ``New Litigation''. I think that just about says it all ... I'm seeking refugee status in Mouc-Mouc islands ;-) Éric.Article: 31894
Peter Alfke wrote: > > Later we checked larger circuits by crawling on the floor. > Those were the days. Not necessarily better, though. An example of this can be seen in the 'Art Of Electronics' (Its a book!) Under the computer or semi's section at the back if I remember corretly (That reminds me - must go dust it!). Cyber_spook_manArticle: 31895
Is anyone looking for an Hardware engineer? Or can anyone recommend a good agent? I live in the South East of the UK Regards Cyber_spook_man pjc@cyberspook.freeserve.co.ukArticle: 31896
Hi Peter,
You can find the interface at
http://www.xilinx.com/ipcenter/rapidio_lounge/rio_8phy.htm. The data sheet
link on the right contains a table of signal descriptions.
Jason
Petter Gustad wrote:
> I noticed that Xilinx announced RapidIO support on their Web site. Is
> this simply that they support LVDS IO compatible with RapidIO, or is
> it a core which supports the entire RapidIO physical layer interface?
> If it's the latter, how does the interface to this core look like?
>
> Thanks
> Petter
>
> --
> ________________________________________________________________________
> Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com
> #include <stdio.h>/* compile/run this program to get my email address */
> int main(void) {printf ("petter\100gustad\056com\nmy opinions only\n");}
Article: 31897
Ben,
I don't use sockets -- they get in the way of the high speed signals
people want to use nowdays.
Austin
Ben Franchuk wrote:
> Austin Lesea wrote:
> > I can't resist.
> { big snip }
>
> In my case I was thinking of CPU's like 8080 Z80 386 586.
> I for some reason I like to have chips in sizes no larger than
> 84 PLCC's. Could be that sockets are a factor - $1 vs $100.
> What about the ROM cost and programing cost?
> Ben.
Article: 31898
Ben Franchuk wrote:
> > Ah! the good old days when you could count pins on ones fingers and toes.
> > Also what ever happened to LOW COST chips like $25 not $250 or $2,500.
> Austin Lesea wrote:
> > I can't resist. the Virtex II 2V40 is less than ~$25 in quantities
> { big snip }
>
> In my case I was thinking of CPU's like 8080 Z80 386 586.
> I for some reason I like to have chips in sizes no larger than
> 84 PLCC's. Could be that sockets are a factor - $1 vs $100.
> What about the ROM cost and programing cost?
$25 is not LOW COST :-)
Even $2.50 is significant in some silicon sectors.
8032, romless 8 bit uC, are available for about 60c, 40/44 pins, and
I think Z80's are still used, for under $2
-jg
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