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
"Randy Yates" <yates@ieee.org> wrote in message news:<d5p1nj1u.fsf@ieee.org>... > scottf3095@aol.com writes: > > >> 4. Design from the top down. That is, begin the design decomposition > >> at the top level and then iteratively break the higher level blocks > >> into lower level blocks. AKA hierarchical design. > > > > ... > > > >> 5. Implement from the bottom up. > > > > Why implement from the bottom up? > > Because part of the implementation usually includes "unit" testing, or > testing of the pieces, and you must begin such testing with the > smallest pieces possible. Then, when the "foundation" is implemented, > you can begin assembling the foundational pieces into small > subsystems, test those, then piece those together, test those, etc., > until you have the entire system. Is there any other reason besides "to support unit testing" to implement from the bottom up? I was wondering if the people that have problems with TDD might be the people that are used to implementing form the top down. I have always coded from the top down. I make a user interface, then start figuring out how what is needed to support the user interface. I add stub classes with comments like "UNDONE" or "TODO". When I can search my entire project and I don't find any of these comments, then I'm done. Of course this method has made adopting TDD very diffucult for me. Does anyone else prefer top down to bottom up development? and has that hindered your adoption of TDD?Article: 87776
"Peter K." <p.kootsookos@iolfree.ie> wrote in message news:<1122745043.996259.309120@g43g2000cwa.googlegroups.com>... > > In software, you can start off implementation at a high-level of > abstraction and just "stub-out" the detail until you're ready to deal > with it. When I start implementing software, I don't (necessarily) > start implementing a function... I first figure out what modules / > classes / components need to be there and instantiate them. Then I > figure out what external interfaces those classes need to present to > each other. Etc. etc. > Do you find that this impairs your ability to apply unit tests, specifically as TDD? -Scott FryeArticle: 87777
scott frye wrote: > Is there any other reason besides "to support unit testing" to > implement from the bottom up? I was wondering if the people that have > problems with TDD might be the people that are used to implementing > form the top down. Yep. Top down design often produces a module split which looks great at first sight, but doesn't play out too well in practice. It might be clumsy to implement, or it might produce inefficient results. Also top down often produces a split which doesn't match well with existing code, and inhibits reuse of that code. Implementing bottom up makes you aware of these issues at an early stage, while reworking the top down design is still a fairly lightweight task. Regards, SteveArticle: 87778
Your question is not very clear. Some more details perhaps ... Rgds Andr=E9Article: 87779
Lik, This is strange, because I have just started having the same problem the very last Friday. I have a V2 3000 device, and I am using BUFGMUX, the one located at P7 location (for this synthesis, I do not lock them). This BUFGMUX guy multiplexes between one external and one internal clock. I output all 4 signals of BUFGMUX on the test pins and I see that when S is '1', the output is not equal to I1 input !!! I verify at least by FPGA Editor that the connections of BUFGMUX are ok. So, I am going for another board with another FPGA and I will also check that the pins are not shorted, but any other suggestions from everybody are always welcome. Vladislav "lik" <like609@163.com> wrote in message news:1122828915.989337.299330@z14g2000cwz.googlegroups.com... > For test my fpga clock, I input a clock throuth one of the dedicated > clock pad, and output it from a general I/O. From the oscillograph, I > found some clock pads can give the correct signal, and the same clock > input the other clock pads only have the '1' output. > > p.s. I use the same vhdl code as follows: clkin-->ibufg-->clkout. > Just differences in assign clock pins. > > Any comments would be appreciated! thank you in advance! >Article: 87780
There is a good test bench generator called "synapticad". Its ver good. u can draw your timing diagrams in it and can generate verilog or VHDL test benches from that. Its available for free trial of 15 days.....Article: 87781
I found some verilog code for the XORXY etc. But for one component OBUF there is a line "GTS = glbl.GTS;" whats this means and model sim XE version is giving "unresolved symbol" while loading the design. How can i avoid the error?? regards SumeshArticle: 87782
i have no idea. i am new in these things as well. try it and see what happens. cheersArticle: 87783
Hi john... I tried the first way but it did gave an error. But the second method did not gave an error but i dont know whether it is initialised prperly. The set pin is still tied to the ground. Can we assume that the stet is '1' ? Sorry for this late replay.... regards SumeshArticle: 87784
Is there anyone that knows some "rule of tumb" when creating a linkerscript? the elffile gives me a good idea on how big the program will be, but the sizes on the stack- and the heep is only a wild guess for me. I have sometimes a hard time debugging the MicroBlaze because the debugger is somethimes running out of scope, but that happends somethimes with very big stacks- and heaps too. Is it yust something I have to live with or might there be something else that I have overlooked? RaymondArticle: 87785
Working out required stack size isn't easy. One way is to build a call tree (ftp://ftp.berlios.de/pub/calltree/), and then print out the stack pointer in the leaf functions. Cheers, JonArticle: 87786
Hi Sumesh, As you load your design, make sure you compile also the module called glbl.v (it's located in the xilinx libraries). And when you load the design, load your top module along with glbl module. Vladislav "vssumesh" <vssumesh_asic@yahoo.com> wrote in message news:1122902465.934947.174040@z14g2000cwz.googlegroups.com... >I found some verilog code for the XORXY etc. But for one component OBUF > there is a line "GTS = glbl.GTS;" whats this means and model sim XE > version is giving "unresolved symbol" while loading the design. How can > i avoid the error?? > regards > Sumesh >Article: 87787
Steve Underwood wrote: > scott frye wrote: > >> Is there any other reason besides "to support unit testing" to >> implement from the bottom up? I was wondering if the people that have >> problems with TDD might be the people that are used to implementing >> form the top down. > > > Yep. Top down design often produces a module split which looks great at > first sight, but doesn't play out too well in practice. It might be > clumsy to implement, or it might produce inefficient results. Also top > down often produces a split which doesn't match well with existing code, > and inhibits reuse of that code. Implementing bottom up makes you aware > of these issues at an early stage, while reworking the top down design > is still a fairly lightweight task. I'd like to illuminate that with an example. One project needed to control a bunch of switches, implemented as bit-I/O . The top-down plan called for the functions (in C usage) on(), off(), and toggle(). It was known at planning time that actual outputs would be word wide. The bottom-up design immediately turned up a snag. The I/O device's state couldn't be read, so an image of its state would need to be kept in memory. With the switch bank serving several tasks, that might have necessitated the inclusion of an otherwise unneeded semaphore system. Discovering that late in a top-down implementation would have meant a lot of code rework. (That's all subjunctive because I built hardware to avoid the problem. The freedom to do that isn't always to be had.) Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87788
pinod01@sympatico.ca wrote: > Hi there group, > > I'm implementing a user defined Master interface to the Avalon Bus > using Altera's Stratix FPGA and read through the documentation on the > Avalon Bus requirements and the SDRAM controller as a slave, and I'm > still not quite getting how the SDRAM controller interprets an address > supplied by a Master peripheral? The SDRAM has a total of 22 bits (12 > bits row, 8 bits column, & 2 bits bank). I am provisioning the address > width on my master to be 32 bits wide of which the top 10 bits are > stuffed with 0's and the remaining bits are column-row-bank > respectively. Is this a correct understanding on how to provide the > address to the slave peripheral sdram controller? If not, I'm > definitely missing something here. > > Also I suspect this provided address is also de-correlated from the > address assigned in the SOPC builder configuration wizard? That if i > have a Master peripheral talking to multiple slaves at different clock > cycles within my state machine, how do I specify which slave peripheral > I am targetting and guarantee that I'm talking to the right one? > Pino, It is much easier than you think. With Avalon, your master emits the address it wants, and that is all there is to it. SDRAM appears as an addressable range of memory (depending on the size of the SDRAM device you're interfacing to). There is no need to worry about column-row-bank business; the SDRAM controller handles that for you. For your second question, again, you emit the address you want to along with a read or write signal and that's it; the generated Avalon bus logic then accesses the appropriate slave peripheral as defined in your address map. Jesse Kempa Altera Corp. jkempa -at- altera -dot- comArticle: 87789
On Mon, 1 Aug 2005 12:20:14 UTC, Steve Underwood <steveu@dis.org> wrote: > scott frye wrote: > > Is there any other reason besides "to support unit testing" to > > implement from the bottom up? I was wondering if the people that have > > problems with TDD might be the people that are used to implementing > > form the top down. > > Yep. Top down design often produces a module split which looks great at > first sight, but doesn't play out too well in practice. It might be > clumsy to implement, or it might produce inefficient results. Also top > down often produces a split which doesn't match well with existing code, > and inhibits reuse of that code. Implementing bottom up makes you aware > of these issues at an early stage, while reworking the top down design > is still a fairly lightweight task. > > Regards, > Steve As with most approaches to any problem, the appropriate method should be used. Properly mixing the top-down and bottom-up methods to your needs. Some problems are best solved by building up a solution, others by decomposing or structuring the proposed solution, a few rare instances may even need a middle-out approach if your existing solution base is the inside (not top or bottom) for the final solution. Refactoring, reworking, or whatever is always available to revise an appropriate solution. Use the techniques that best fit your needs and design approach. DavidArticle: 87790
Hi Yes, actually, I just there are some simulation problems with post-synthesis simulation in my design :) Anyway thankyou for introducing good documents and examples. Cheers.Article: 87791
MM wrote: > Hi Pavel, > > > Currently I am trying to design a system with ADC -> ISSI RAM -> > > FFTcore -> ISSI RAM -> DAC. > > What does ISSI stands for? ISSI is a chip vendor. -aArticle: 87792
vssumesh wrote: > There is a good test bench generator called "synapticad". Its ver good. > u can draw your timing diagrams in it and can generate verilog or VHDL > test benches from that. As much as I think that Synapticad's timing diagram tool is pretty neat, I think that test benches generated from timing diagrams are unmaintainable and not very helpful. A proper test bench will have bus-functional models of the ADC and DAC digital interfaces, and a model of the SRAM, all connected to the device-under-test (the FPGA). Yes, it takes more work to create these models, but you do it once and you can use them on all of your designs. -aArticle: 87793
Jerry Avins wrote: > Steve Underwood wrote: > >> scott frye wrote: >> >>> Is there any other reason besides "to support unit testing" to >>> implement from the bottom up? I was wondering if the people that have >>> problems with TDD might be the people that are used to implementing >>> form the top down. >> >> >> >> Yep. Top down design often produces a module split which looks great >> at first sight, but doesn't play out too well in practice. It might be >> clumsy to implement, or it might produce inefficient results. Also top >> down often produces a split which doesn't match well with existing >> code, and inhibits reuse of that code. Implementing bottom up makes >> you aware of these issues at an early stage, while reworking the top >> down design is still a fairly lightweight task. > > > I'd like to illuminate that with an example. One project needed to > control a bunch of switches, implemented as bit-I/O . The top-down plan > called for the functions (in C usage) on(), off(), and toggle(). It was > known at planning time that actual outputs would be word wide. The > bottom-up design immediately turned up a snag. The I/O device's state > couldn't be read, so an image of its state would need to be kept in > memory. With the switch bank serving several tasks, that might have > necessitated the inclusion of an otherwise unneeded semaphore system. > Discovering that late in a top-down implementation would have meant a > lot of code rework. (That's all subjunctive because I built hardware to > avoid the problem. The freedom to do that isn't always to be had.) > > Jerry If you built the hardware to avoid the problem after it was discovered then it's evidence to support bottom-up implementation -- because the problem would not have been discovered at the bottom of the software to be fixed at an even lower level. -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 87794
Hello everyone!
I am having a problem in ModelSim XE 5.8c with a very simple
bidirectional bus.
ModelSim outputs a bunch of XXXX's where its supposed to output data.
I am using test bench waveforms with Xilinx ISE 6.303i.
Basically there are only 3 signals: the bidir. bus, wr_enable and clk.
The idea behind this simple code is:
if WR_EN is HIGH -> store bus data into a flip-flop on next clock edge.
else WR_EN is LOW -> output a constant value on the bus (in practice, I
want to output something more useful, of course.)
Unfortunately, ModelSim outputs X's (don't cares) for every bit where
the data in flip-flop conflicts with the constant.
Let's say that 11110000 was stored in the flip-flop when WR_EN was
high.
And suppose that the constant to put on the bus is 00110000, when WR_EN
goes low.
When WR_EN actually does go low, ModelSim will output XX110000 instead
of 00110000.
I think the problem might be with the way I designed the bus with VHDL.
But I can't figure out where the problem is, and the code is VERY
simple.
Any help on this and maybe references to reading materials on
bidirectional/tristate bus implementation in VHDL would be highly
appreciated!
Thanks,
Pavel
Here is the code:
------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
------------------------------
ENTITY bidir_bus IS
PORT(
bidir : INOUT STD_LOGIC_VECTOR (7 DOWNTO 0);
WR_en, clk : IN STD_LOGIC);
END bidir_bus;
------------------------------
ARCHITECTURE Behavioral OF bidir_bus IS
SIGNAL a : STD_LOGIC_VECTOR (7 DOWNTO 0); -- DFF that stores
-- value from input.
BEGIN
PROCESS (WR_en, clk)
BEGIN
IF( WR_en = '1') THEN
bidir <= "ZZZZZZZZ";
IF(clk'EVENT and clk='1') THEN
a <= bidir;
END IF;
ELSE
bidir <= "11110000"; -- simply output a constant on the bus
-- of course, in practice I would like to
-- output something else.
END IF;
END PROCESS;
END Behavioral;
------------------------------
Article: 87795> You probably will need a simple state machine to control the data flow. It > will sit in the idle state waiting for a start condition. As soon as it > happens it will go into the fill_input_buffer state, etc... I am trying to design with state machines. For example there is a master FSM (finite state machine), which calls slave state-machines along the way, waits for them to end (via slave-busy signals) etc... Unfortunately this approach becomes very messy very quickly. So, I decided to look at the professional code, such as PicoBlaze soft processor code, and some video application examples on Xilinx website and although there are certainly state machines here and there, it seems that most of the code is kind of .......... architectural. In other words there are many components and control signals. I understand the breakdown into components when somebody else writes it, and I understand the code, and how everything is connected. The problem arises when I need to come up with all the control signals myself, and make sure the dynamics of the system is working ok. I think thats a digital design problem, rather than a coding problem. Coding is *relatively* easy when you have a clear design. Thats why I was wondering how the more experienced folks come up with their designs. >Yes, you should start with a block diagram, but the dataflow you mentioned > is essentially the one. > 1. Does it have it run continiously or in bursts? It bursts, the idea is that much high frequencies can be sampled, by simply loading all the data into high speed memory. The FFT will then work on the data in RAM, because its not fast enough to process data in real-time. Once FFT is finished it stores the results in another block of high-speed RAM. The architecture of the FFT core is such that once it unloads the results, it loses them forever. However, if the results are stored in RAM, then you can output them continuously (for example to DAC, for viewing on the scope). And other blocks (to be added eventually) will be able to access the results if they need to. For example a USB link to PC for data processing could use them.Article: 87796
Up to now, I have been doing much of my work with ModelSim and a BMP file reader and writer. Most of my VHDL designs have clk and reset. I know where to attach the clk but what do I use for reset. An external pin? The Done pin? Or a DCM lock signal? Brad Smallridge b r a d @ a i v i s i o n . c o mArticle: 87797
Hi: I am reading the FAQ on Spartan3 here: http://www.xilinx.com/products/spartan3/faq105_s3.pdf which says only XC3S50 is supported by WebPack 5.2i. I realize this is an old version (though the one I am still using since I had trouble with 6.1i). Now we are at 7.1i, which indicates support for Spartan3 of course here: http://www.xilinx.com/ise/logic_design_prod/webpack.htm but doesn't indicate the details about whether it supports larger Spartan3 devices or not. Specifically, I am considering XC3S400. Does WebPack 7.1i support that or do I need to start spending $$$ ? Thanks for input. Good day! -- _______________________________________________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarleRemoveThis@BOGUSsandia.gov NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.Article: 87798
Not sure about your code. There might be
an issue with the nesting of the if statements and
whether the sensitivity list will allow both "ifs"
to happen at the same time. You might want
to rethink that.
Here is my code that I know works:
sram_read_data_pins_process:process(clk,reset)
begin
if(reset='1') then
sram_read_data <= (others => '0');
elsif(clk'event and clk='1') then
if(sram_state_2 = sram_state_read ) then
sram_read_data( 8 downto 0) <= sramdqa;
sram_read_data(17 downto 9) <= sramdqb;
sram_data_valid <= '1';
else
sram_data_valid <= '0';
end if;
end if;
end process;
sram_outgoing_data_pipeline:process (clk,reset)
begin
if(reset='1') then
sram_write_data_1 <= (others => '0');
sram_write_data_2 <= (others => '0');
elsif(clk'event and clk='1') then
sram_write_data_1 <= sram_write_data_0;
sram_write_data_2 <= sram_write_data_1;
end if;
end process;
sramdqa <= sram_write_data_2( 8 downto 0) when (sram_w_3 = '0') else
(others=>'Z');
sramdqb <= sram_write_data_2(17 downto 9) when (sram_w_3 = '0') else
(others=>'Z');
Article: 87799I'm trying to create a customized BRAM module (memory redundancy, checkbits) However, the BRAM included in the EDK cannot be simply modified (no hdl in the ip core directory). Does anyone know of anyways to modify it?
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