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
Hi David, The .mpd file looks ok and can't be the reason why you can't compile hello-world on both processors. The problem is more likely on how you have setup the software for your project. You need two hello-world, one for each MicroBlaze and you have to assign the software project to each of them. Göran "David Chen" <jogchen@gmail.com> wrote in message news:1188597136.748819.197680@m37g2000prh.googlegroups.com... > Hi, I would like to create a system like below: > > uBlaze <=one pair of FSL=> customized IP <=another pair of FSL=> > uBlaze > > Could anyone tell me whether it is possible to do that? Is there any > constraint about the number of FSL pairs each customized IP can have? > > I modified the .mpd by simply duplicating the ports'' names like > below. I also duplicated the ports and HDL in IP''s HDL file. Then > connecting the system like: > > uBlaze_0 <=MFSL,SFSL=> customized IP <=M2,S2=> uBlaze_1 > > Synthesizing, par, generating Bitstream seem to be ok. while I have an > error when I wanted to compile hello-world programs on both > processors. Could anyone give me some advice that where can be the > wrong part? > Thanks a lot. > David > > ================================= > > BEGIN custom_ip > > ## Peripheral Options > OPTION IPTYPE = PERIPHERAL > OPTION IMP_NETLIST = TRUE > OPTION HDL = VERILOG > OPTION CORE_STATE = DEVELOPMENT > OPTION IP_GROUP = MICROBLAZE:PPC:USER > > > ## Bus Interfaces > BUS_INTERFACE BUS = SFSL, BUS_TYPE = SLAVE, BUS_STD = FSL > BUS_INTERFACE BUS = MFSL, BUS_TYPE = MASTER, BUS_STD = FSL > BUS_INTERFACE BUS = S2, BUS_TYPE = SLAVE, BUS_STD = FSL > BUS_INTERFACE BUS = M2, BUS_TYPE = MASTER, BUS_STD = FSL > ## Generics for VHDL or Parameters for Verilog > > ## Ports > PORT FSL_Clk = "", DIR = I, SIGIS = CLK, BUS = SFSL:MFSL > PORT FSL_Rst = OPB_Rst, DIR = I, SIGIS = RST, BUS = SFSL:MFSL > PORT FSL_S_Clk = FSL_S_Clk, DIR = O, SIGIS = Clk, BUS = SFSL > PORT FSL_S_Read = FSL_S_Read, DIR = O, BUS = SFSL > PORT FSL_S_Data = FSL_S_Data, DIR = I, VEC = [0:31], BUS = SFSL > PORT FSL_S_Control = FSL_S_Control, DIR = I, BUS = MFSL > PORT FSL_S_Exists = FSL_S_Exists, DIR = I, BUS = SFSL > PORT FSL_M_Clk = FSL_M_Clk, DIR = O, SIGIS = Clk, BUS = MFSL > PORT FSL_M_Write = FSL_M_Write, DIR = O, BUS = MFSL > PORT FSL_M_Data = FSL_M_Data, DIR = O, VEC = [0:31], BUS = MFSL > PORT FSL_M_Control = FSL_M_Control, DIR = O, BUS = MFSL > PORT FSL_M_Full = FSL_M_Full, DIR = I, BUS = MFSL > PORT FSL_Clk_2 = "", DIR = I, SIGIS = Clk, BUS = S2:M2 > PORT FSL_Rst_2 = OPB_Rst, DIR = I, BUS = S2:M2, SIGIS = RST > PORT FSL_S_Clk_2 = FSL_S_Clk_2, DIR = O, SIGIS = Clk, BUS = S2 > PORT FSL_S_Read_2 = FSL_S_Read_2, DIR = O, BUS = S2 > PORT FSL_S_Data_2 = FSL_S_Data_2, DIR = I, VEC = [0:31], BUS = S2 > PORT FSL_S_Control_2 = FSL_S_Control_2, DIR = I, BUS = S2 > PORT FSL_S_Exists_2 = FSL_S_Exists_2, DIR = I, BUS = S2 > PORT FSL_M_Clk_2 = FSL_M_Clk_2, DIR = O, SIGIS = Clk, BUS = M2 > PORT FSL_M_Write_2 = FSL_M_Write_2, DIR = O, BUS = M2 > PORT FSL_M_Data_2 = FSL_M_Data_2, DIR = O, VEC = [0:31], BUS = M2 > PORT FSL_M_Control_2 = FSL_M_Control_2, DIR = O, BUS = M2 > PORT FSL_M_Full_2 = FSL_M_Full_2, DIR = I, BUS = M2 > > END >Article: 123726
Hi, Although not entirely accurate, this paper can be a starting point: http://www.eecg.toronto.edu/~jayar/pubs/kuon/kuontcad06.pdf At least you can have a reference to it, unlike to a hammer-job. Similarly, this paper gives you some idea what your sizes would be if you would go on and make your own FPGA: http://www.ece.ubc.ca/~stevew/papers/pdf/fpga2007a.pdf -Doug On Aug 31, 11:16 am, Pasacco <pasa...@gmail.com> wrote: > I just need to know some technology data, for example, "die size" and > "LUT size", in order to compare different designs. > As far as I know, these technology data are not available anywhere.Article: 123727
On 29 ago, 15:26, harshada.pen...@gmail.com wrote: > On Aug 29, 12:51 pm,Pablo<pbantu...@gmail.com> wrote: > > > Hi, I have implemented a core to write/read to a Bram_Block (using one > > of the two ports). The another port is used by Microblaze with a > > lmb_bram_if_cntlr core to read those values which had been modified by > > my custom core. Of course, I use a lmb bus. > > > Now, I want to create a design with PowerPC and I suppose I must use a > > plb bus to access to the bram_block. With this assumption, PowerPC > > would use a plb_bram_if_cntlr core to read from the bram (this works > > fine), but my custom core cannot modify the contents of the bram. > > > What's wrong?. Is plb bus very different from lmb?. Could I use a lmb > > bus with PowerPC instead of Microblaze? > > > Best Regards > > HiPablo, > > I want to ask u how u are able to read the block ram by microblaze. > > U said u had used lmb_bram_if_cntlr core to read the BRAM. then r u > using the same lmb bus used by microblaze to access data( in > instruction). Then in C code which instruction u had used to read BRAM > data. > > Would u please explain ur design > > Thanks and regards, > Harshada Of course. You have to create a bram block and the a core to access it with PortA (for example). I have use lmb bus and lmb core. Finally you have to export to ISE and add another "custom" core in vhdl to access to the another port (in this case B). It's very simple. Best Regards. PabloArticle: 123728
On 2 Sep, 23:44, Andreas Ehliar <ehl...@lysator.liu.se> wrote: ... > > Should have said that part of the design is a large crossbar switch. > > It may be relevant to the number of gates and/or the design style. > > How large is "large"? But it should be fairly simply to calculate the > size of a crossbar switch. Shooting from the hip somewhat I think I could start with about seven ports (to test the concept) each being 8-bit. I need to pass a strobe with each input to the switch and possibly an acknowledge fed /back/ from each output. So there would be 10 bits (8 data + 1 strobe + 1 ack) per port leading, I think, to a 70x70 crossbar. > Assuming the switch is implemented using muxes: > A 2-to-1 mux uses 1 LUT > A 4-to-1 mux uses 2 LUTs > An 8-to-1 mux uses 4 LUTs > A 16-to-1 mux uses 8 LUTs > (and so on) If it were implemented on bare silicon I think it could be made from one transistor or possibly a pair of transistors per junction. The main problem in that case would be routing of inputs, outputs and controls. For an FPGA I had no idea how it could be implemented. Thanks for the tip on using muxes. Do you mean each output would be fed from an 8-to-1 mux (to select the appropriate input line for each output)? So I would need 70 such muxes? > Multiply this with the number of ports and the width of each port to > get a rough total LUT cost. (Ignoring the cost of the arbiter or > other configuration logic for the crossbar.) > > An XC3S200 has 3840 LUTs if I calculate correctly. So an 8x8 crossbar > with 8 bit wide ports should fit fairly comfortable whereas for example > a 16x16 crossbar of width 16 will consume half the FPGA. > > How often do you need to reconfigure the inputs/outputs of the > crossbar? If it is not very often, perhaps you could serially load > configuration data into SRL16 elements to reduce the number of > required LUTs. The crossbar's mapping of inputs to outputs would change potentially every system 'cycle' though instead of using clock cycles I intend to use handshaking to sync transfers. This is part of the concept: 1) faster since compute elements do not have to wait for the next clock cycle in order to complete their work and 2) lower power consumtion because the system is not clocked. Someone will probably tell me this has already been done, though, or is not effective. Maybe I'm reinventing a wheel and one not as good as existing ones.... > What kind of bitrate do you need through the crossbar? Perhaps you > could use a time-multiplexed bus instead? The rate isn't important at this stage. I want to test a concept rather than make a production system. Yes, one option is to have tri- state output latches on the elements and, rather than have them talk through a switch, have them talk over a couple of buses instead. I may need output latches anyway. I understand I can write this in VHDL or Verilog. Any suggestions on whether a newbie like me should use a particular style of description to implement the above? I guess I should avoid gate level to avoid too much complexity and also avoid high-level concepts so it can be readily synthesized. Is that about right? -- JamesArticle: 123729
On Sun, 02 Sep 2007 22:38:38 GMT, "KJ" wrote: >For whatever tools that you have that meet the following two tests, did you >open a service request? >- Tool claims compliance to VHDL standard >- Tool does not error (or at least warning) about ignoring the initial value >assignment Every synth tool I've used issues a warning or error when it ignores initial values. It's a tool restriction I've learnt to live with. On FPGAs with well-defined config values, I work around it by providing an explicit asynchronous reset in the usual way and then tying-off that reset to "false" somewhere in the top-level wrapper that organises the design for the target platform. That gives me no additional hardware cost in the FPGAs that I've used, and it gives me a different, clumsier, but equally effective way to specify initial values. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 123730
Benni V. <benniv.sep08@googlemail.com> wrote: > Hi, > On 31 Aug., 14:00, Uwe Bonnes <b...@hertz.ikp.physik.tu-darmstadt.de> > wrote: > > > [4] XAPP452 http://www.xilinx.com/bvdocs/appnotes/xapp452.pdf > > Hope this helps > thanks for your help. > Actually I think I found the commands in the *.rbb-file, which, > according to XAPP452, starts with the binary command sets. > So, for reference, here the commands which hopefully work :-) > 0xffff ffff // Sync > 0xaa99 5566 // Sync > 0x3001 c001 // IDCODE Register > 0x01c2 2093 // XC3S500E > 0x3000 2001 // FAR Write Packet Header > 0x0000 0000 // FAR Write Packet Data (0h) > 0x3000 8001 // CMD Write Packet Header > 0x0000 000b // CMD Write Packet Data (SHUTDOWN) > 0x3000 8001 // CMD Write Packet Header > 0x0000 0007 // CMD Write Packet Date (RCRC) > 0x2000 0000 // NOP > 0x2000 0000 // NOP > 0x2000 0000 // NOP > 0x2000 0000 // NOP > 0x3000 8001 // CMD Write Packet Header > 0x0000 0004 // CMD Write Packet Data (RCFG) > 0x2800 6000 // FDRO Read Packet Header (Type 1) > 0x4801 149a // FDRO Read Packet Header (Type 2), Word-Counter 1149Ah > ... ... ... > 0x3000 8001 // CMD Write Packet Header > 0x0000 0005 // CMD Write Packet Data (START) > 0x3000 8001 // CMD Write Packet Header > 0x0000 0007 // CMD Write Packet Data (RCRC) > 0x3000 8001 // CMD Write Packet Header > 0x0000 000d // CMD Write Packet Data (DESYNCH) > 0x2000 0000 // NOP > 0x2000 0000 // NOP > 0x2000 0000 // NOP > 0x2000 0000 // NOP Please keep us informed and eventually send patches to sourceforge. Thanks -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 123731
> It is possible to have a format of .pof/.sof files from Altera, thus, > to decompile some ready projects and try to make our own, omitting > Altera software tools? BTW, is the same possible with Xilinx?Article: 123732
On 2007-09-03, drop669@gmail.com <drop669@gmail.com> wrote: >> It is possible to have a format of .pof/.sof files from Altera, thus, >> to decompile some ready projects and try to make our own, omitting >> Altera software tools? > > BTW, is the same possible with Xilinx? I don't know what kind of format .pof/.sof is, but for Xilinx you have the xdl tool available that can convert a .ncd file into a .xdl file. The .xdl file will contain an ASCII representation of your place and routed circuit. (You can also do it before routing to only get the mapped circuit.) You might also be interested in JBits (Java library for manipulating Xilinx design. Sadly it has been discontinued and does not support anything newer than Virtex-II.) ABits might also be interesting if you are interested in Atmel FPGAs. (Google ABits and Atmel.) I have also seen that some people have reverse engineered part of the Xilinx bitstream format. There was a link to a "debit" utility posted a couple of month ago which could take a .bit file and present a view similar to the FPGA editor. The website was quickly taken down and the author said that he didn't intend the tool to become publicly known before it was more finished if I remember correctly. Debit was available at http://www.ulogic.org/trac before it disappeared. I also saw that at least one research group at FPL 2007 had done some reverse engineering of the Xilinx Bitstream format. Not sure if they are affiliated with "debit" or not. (If you are interested in the XDL format I have written a small library in Python that can do some simple manipulation of XDL files. It is enough to insert a logic analyzer into a placed and routed design. It is not quite cleaned up yet but it should be released before FPGAworld in Stockholm this year. (before 13th september)) /AndreasArticle: 123733
On 2007-09-03, Weng Tianxiang <wtxwtx@gmail.com> wrote:
|-----------------------------------------------------------------------------------------|
|"On Aug 29, 3:13 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org> |
|wrote: |
|> Jim, |
|> |
|> On 2007-08-28, Jim Lewis <j...@synthworks.com> wrote: |
|> |
|[..] |
|> |--------------------------------------------------------------------------| |
|> |"[..] | |
|> | | |
|> |[..] The danger in adding new keywords is that they may | |
|> |conflict with a name (signal, ...) already used in someone's design | |
|> |and cause an old design to be a syntax error in the new language | |
|> |revision. This generally does not please people and means they | |
|> |have to add special handling for the file (compile flags). | |
|> | | |
|> |[..]" | |
|> |--------------------------------------------------------------------------| |
|> |
|> A newly introduced reserved word would be guaranteed to not conflict |
|> with old code by not being possible to misinterpret as a basic |
|> identifier (basic_identifier ::= letter { [ underline ] |
|> letter_or_digit), e.g. by starting with an underline or by containing |
|> a percentage sign. |
|> |
|> Best regards, |
|> Colin Paul |
| |
|Hi Colin, |
|I have difficulties to understand following segment you are talking |
|about the name conflicts. |
| |
||[..] The danger in adding new keywords is that they |
|may | |
||conflict with a name (signal, ...) already used in someone's |
|design | |
||and cause an old design to be a syntax error in the new |
|language | |
||revision. This generally does not please people and means |
|they | |
||have to add special handling for the file (compile |
|flags). | |
|| |
|| |
|| |
|[..]" |
|| |
||--------------------------------------------------------------------------| |
| |
| |
|A newly introduced reserved word would be guaranteed to not conflict |
|with old code by not being possible to misinterpret as a basic |
|identifier (basic_identifier ::= letter { [ underline ] |
|letter_or_digit), e.g. by starting with an underline or by containing |
|a percentage sign. |
| |
|I would like to know what Jim's name conflicting mechanism is. |
| |
|1. Here I have an old file using the following statements: |
|assertion zero_one_hot(); -- the function was defined in an old file |
| |
|Here I have another new file using the following statements: |
|assertion zero_one_hot(); -- try to refer to Jim's function. |
| |
|Those two above files must be compiled together using 2006 version. |
|What happens? |
| |
|No name conflicting?" |
|-----------------------------------------------------------------------------------------|
Weng,
Please reread
news:13ddnbc8cckdr7b@corp.supernews.com
in which it was confirmed that the function is not called zero_one_hot
but is called onehot0 and which has already been part of the PSL
standard for over a year
and please reread
news:slrnfddf2i.828.Colin_Paul_Gloster@mizar.iet.unipi.it
in which it is pointed out that the name conflict would appear only in
PSL (and that it would still be possible to use the name with a
conflict) unlike introducing your keyword which would affect not only
every PSL file which already had the name orif, but also every VHDL
file which already had the name orif.
|-----------------------------------------------------------------------------------------|
|"2. Here is orif name conflicting. |
| |
|Here I have an old file containing orif as a signal and has the |
|following statements. |
| |
|Signal orif : std_logic; |
|... |
|If(orif = ...) then" |
|-----------------------------------------------------------------------------------------|
An if statement does not need ( nor ) in this manner.
|-----------------------------------------------------------------------------------------|
|"Here I have an new file containing orif as a signal and has the |
|following statements. |
| |
|Signal orif : std_logic; |
|... |
|If(orif = ...) then |
| |
|When the old file is compiled by new 2006 version, what would happen |
|with above two statements?" |
|-----------------------------------------------------------------------------------------|
It would work (if you remove the parentheses).
|-----------------------------------------------------------------------------------------|
|" When the new file is compiled by new 2006 |
|version, what would happen with above two statements?" |
|-----------------------------------------------------------------------------------------|
The contents of the new file are identical to the contents of the old
file and the files will be treated identically.
|-----------------------------------------------------------------------------------------|
|"How does 2006 version know that what it deals with is an old file or a |
|new file with your method?" |
|-----------------------------------------------------------------------------------------|
It does not need to.
|-----------------------------------------------------------------------------------------|
|"Jim, here is my solution to your naming conflicting problem. |
| |
|VERY SIMPLE AND COMPLETE !!! |
| |
|If a 2006 version compiler uses file date to distinguish old file or |
|new file by reading their file generation year, before 2007 and after |
|2007, there is no any trouble to deal with new or old files and both |
|files can safely be compiled without error. |
| |
|[..]" |
|-----------------------------------------------------------------------------------------|
Not acceptable. Some people still code in VHDL87. Some people code in
VHDL93. Setting a tool switch can be used to choose the language. When
something was written (which could simply have been copied from a
VHDL87 book in 2010 or could have been a ten year old file whose time
stamp was changed because comments were reformatted) does not indicate
what it was written for.
Regards,
Colin Paul Gloster
Article: 123734On 2007-09-03, James Harris <james.harris.1@googlemail.com> wrote: > Thanks for the tip on using muxes. I think muxes are your best bet. > Do you mean each output would be fed from an 8-to-1 mux (to select the > appropriate input line for each output)? So I would need 70 such > muxes? Yes. (Assuming 10 bits are enough for your design.) That shouldn't take too much space. > cycle in order to complete their work and 2) lower power consumtion > because the system is not clocked. Someone will probably tell me this > has already been done, though, or is not effective. Maybe I'm > reinventing a wheel and one not as good as existing ones.... I don't remember any exact reference now but I remember reading postings on this group saying that it might be better to pipeline an FPGA design more than you might think since hazard spikes propagating through a long net might consume more power than the network itself. Something to keep in mind at least. I haven't tried to verify this myself though. Searching the group should yield some references which you might be interested in evaluating before you start working on this. >> What kind of bitrate do you need through the crossbar? Perhaps you >> could use a time-multiplexed bus instead? > > The rate isn't important at this stage. I want to test a concept > rather than make a production system. Yes, one option is to have tri- > state output latches on the elements and, rather than have them talk > through a switch, have them talk over a couple of buses instead. I may > need output latches anyway. Actually there are no tri-state buffers inside newer Xilinx FPGAs so even for the time-multiplexed bus you would use muxes. (Actually, most of the time when people talk about buses insides FPGAs the bus itself would be implemented using muxes nowadays.) Same thing with ASICs actually, you really want to avoid tri-state buses in an ASIC if you can. If you write a 'Z' in VHDL or Verilog it would be converted into logic that didn't use tri-state buffers. (I would recommend that you didn't use it anyway, in some cases you can get simulation/synthesis mis- match.) /AndreasArticle: 123735
<drop669@gmail.com> wrote in message news:1188777964.492149.314030@g4g2000hsf.googlegroups.com... > Hi. > It is possible to have a format of .pof/.sof files from Altera, thus, > to decompile some ready projects and try to make our own, omitting > Altera software tools? > It would be theoretically possible, but definitley a non-trivial exercise. You've probably noticed the variation in pof/sof size depending on the target chip? You could start by trying various combinations of logic, with forced placement in the same area on the FPGA and see how it changes the format of the pof/sof file. Similarly, repeat the same logic combinations in different areas, and look for repeating pattern in the pof/sof files. ----- Why bother when the tools are (basically) free from ALTERA , and of a very high quality anyway? (imho) RedArticle: 123736
On 2007-09-03, Andreas Ehliar <ehliar@lysator.liu.se> wrote: > Actually there are no tri-state buffers inside newer Xilinx FPGAs so > even for the time-multiplexed bus you would use muxes. Upon thinking about this for a minute or so I realized that I should probably take that back and rephrase it like: "There are no user accessible tri-state buffer inside newer Xilinx FPGAs." In older devices you had TBUFs, but they are no longer available. Longer disclaimer: Since I don't work at Xilinx I have no idea how the routing inside Xilinx devices is actually implemented but it seems like some nets can be driven from either side depending on how the FPGA is configured. That might be implemented with some sort of tristate buffers. (Unless this is just a simplification in the FPGA editor of how it really works. The xdl report file also hints that there are some nets that can be driven in both directions.) Anyway, as a user of the device we don't really have to care about these details. /AndreasArticle: 123737
Hi Austin, austin wrote: > Sean, > > USR_ACCESS_VIRTEX5 > > in > > http://direct.xilinx.com/bvdocs/userguides/ug191.pdf > > page 92: > > "The STARTUP_VIRTEX5 block has inputs that allow the user to take over > the CCLK and DONE pins after the EOS (End-Of-Startup) signal is asserted." > > Not sure, but this sounds like what you need? Thanks for the quick reply. Yes, that should work. STARTUP_VIRTEX5 has an input that enables me to tristate the CCLK pin ater configuration, which is exactly what I need. cu, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 123738
On Sep 3, 5:31 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:
> On 2007-09-03, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> |------------------------------------------------------------------------=
--=AD---------------|
> |"On Aug 29, 3:13 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org> =
|
> |wrote: =
|
> |> Jim, =
|
> |> =
|
> |> On 2007-08-28, Jim Lewis <j...@synthworks.com> wrote: =
|
> |> =
|
> |[..] =
|
> |> |---------------------------------------------------------------------=
-----=AD=AD| |
> |> |"[..] =
| |
> |> | =
| |
> |> |[..] The danger in adding new keywords is that they may =
| |
> |> |conflict with a name (signal, ...) already used in someone's design =
| |
> |> |and cause an old design to be a syntax error in the new language =
| |
> |> |revision. This generally does not please people and means they =
| |
> |> |have to add special handling for the file (compile flags). =
| |
> |> | =
| |
> |> |[..]" =
| |
> |> |---------------------------------------------------------------------=
-----=AD=AD| |
> |> =
|
> |> A newly introduced reserved word would be guaranteed to not conflict =
|
> |> with old code by not being possible to misinterpret as a basic =
|
> |> identifier (basic_identifier ::=3D letter { [ underline ] =
|
> |> letter_or_digit), e.g. by starting with an underline or by containing =
|
> |> a percentage sign. =
|
> |> =
|
> |> Best regards, =
|
> |> Colin Paul =
|
> | =
|
> |Hi Colin, =
|
> |I have difficulties to understand following segment you are talking =
|
> |about the name conflicts. =
|
> | =
|
> ||[..] The danger in adding new keywords is that they =
|
> |may | =
|
> ||conflict with a name (signal, ...) already used in someone's =
|
> |design | =
|
> ||and cause an old design to be a syntax error in the new =
|
> |language | =
|
> ||revision. This generally does not please people and means =
|
> |they | =
|
> ||have to add special handling for the file (compile =
|
> |flags). | =
|
> || =
|
> || =
|
> || =
|
> |[..]" =
|
> || =
|
> ||-----------------------------------------------------------------------=
--=AD-=AD| |
> | =
|
> | =
|
> |A newly introduced reserved word would be guaranteed to not conflict =
|
> |with old code by not being possible to misinterpret as a basic =
|
> |identifier (basic_identifier ::=3D letter { [ underline ] =
|
> |letter_or_digit), e.g. by starting with an underline or by containing =
|
> |a percentage sign. =
|
> | =
|
> |I would like to know what Jim's name conflicting mechanism is. =
|
> | =
|
> |1. Here I have an old file using the following statements: =
|
> |assertion zero_one_hot(); -- the function was defined in an old file =
|
> | =
|
> |Here I have another new file using the following statements: =
|
> |assertion zero_one_hot(); -- try to refer to Jim's function. =
|
> | =
|
> |Those two above files must be compiled together using 2006 version. =
|
> |What happens? =
|
> | =
|
> |No name conflicting?" =
|
> |------------------------------------------------------------------------=
--=AD---------------|
>
> Weng,
>
> Please rereadnews:13ddnbc8cckdr7b@corp.supernews.com
> in which it was confirmed that the function is not called zero_one_hot
> but is called onehot0 and which has already been part of the PSL
> standard for over a year
> and please rereadnews:slrnfddf2i.828.Colin_Paul_Gloster@mizar.iet.unipi.it
> in which it is pointed out that the name conflict would appear only in
> PSL (and that it would still be possible to use the name with a
> conflict) unlike introducing your keyword which would affect not only
> every PSL file which already had the name orif, but also every VHDL
> file which already had the name orif.
>
> |------------------------------------------------------------------------=
--=AD---------------|
> |"2. Here is orif name conflicting. =
|
> | =
|
> |Here I have an old file containing orif as a signal and has the =
|
> |following statements. =
|
> | =
|
> |Signal orif : std_logic; =
|
> |... =
|
> |If(orif =3D ...) then" =
|
> |------------------------------------------------------------------------=
--=AD---------------|
>
> An if statement does not need ( nor ) in this manner.
>
> |------------------------------------------------------------------------=
--=AD---------------|
> |"Here I have an new file containing orif as a signal and has the =
|
> |following statements. =
|
> | =
|
> |Signal orif : std_logic; =
|
> |... =
|
> |If(orif =3D ...) then =
|
> | =
|
> |When the old file is compiled by new 2006 version, what would happen =
|
> |with above two statements?" =
|
> |------------------------------------------------------------------------=
--=AD---------------|
>
> It would work (if you remove the parentheses).
>
> |------------------------------------------------------------------------=
--=AD---------------|
> |" When the new file is compiled by new 2006 =
|
> |version, what would happen with above two statements?" =
|
> |------------------------------------------------------------------------=
--=AD---------------|
>
> The contents of the new file are identical to the contents of the old
> file and the files will be treated identically.
>
> |------------------------------------------------------------------------=
--=AD---------------|
> |"How does 2006 version know that what it deals with is an old file or a =
|
> |new file with your method?" =
|
> |------------------------------------------------------------------------=
--=AD---------------|
>
> It does not need to.
>
> |------------------------------------------------------------------------=
--=AD---------------|
> |"Jim, here is my solution to your naming conflicting problem. =
|
> | =
|
> |VERY SIMPLE AND COMPLETE !!! =
|
> | =
|
> |If a 2006 version compiler uses file date to distinguish old file or =
|
> |new file by reading their file generation year, before 2007 and after =
|
> |2007, there is no any trouble to deal with new or old files and both =
|
> |files can safely be compiled without error. =
|
> | =
|
> |[..]" =
|
> |------------------------------------------------------------------------=
--=AD---------------|
>
> Not acceptable. Some people still code in VHDL87. Some people code in
> VHDL93. Setting a tool switch can be used to choose the language. When
> something was written (which could simply have been copied from a
> VHDL87 book in 2010 or could have been a ten year old file whose time
> stamp was changed because comments were reformatted) does not indicate
> what it was written for.
>
> Regards,
> Colin Paul Gloster
Hi Colin,
OK, I accept your following explanation:
Not acceptable. Some people still code in VHDL87. Some people code in
VHDL93. Setting a tool switch can be used to choose the language.
When
something was written (which could simply have been copied from a
VHDL87 book in 2010 or could have been a ten year old file whose time
stamp was changed because comments were reformatted) does not
indicate
what it was written for.
With compiler switch for different versions, why is there still orif
name conflicting problem?
For 2006 version, keyword orif can be safely used, for old one, there
is no keyword orif.
Thank you.
Weng
Article: 123739Hi Colin, I finally got the right answers and realized that orif is used in 2006 version for other usage. Jim's always suggested that orif would conflict with OLD files. With version switches you mentioned, the Jim's claim has not been true since the beginning. Now it seems to me that any new keywords can be used in a new version if there are version switches and the names are not conflicted within the new versions. Can we use new keyword OIF or _ORIF for the mutually exclusive purpose? OIF is better than _ORIF as a keyword. The fewer letters, the better. How the new keyword is spelled is not essential, but it is essential to introduce a new keyword to provide in-line programming capability. Do you have any reservations about the introduction of new keyword for the purpose? Why? Thank you. WengArticle: 123740
Hello all:)
I am having a problem with the OCM BRAM. I am using virtex II pro and
EDK tools.
I have an OCM BRAM and the PORT B is unconnected. I would like to give
throught a testbench on PORT B data and address vectors. SO i have
done the Port
B of BRAM as "external signals". The question is that is makes two OCM
controllers, the one for Data (Docm_cntlr) and the other for
instruction (iocm_cntlr).
Part of the testbench:
WAIT FOR 30 ns; -- Time=930 ns
dsocm_bram_BRAM_Addr_B_pin <= transport
std_logic_VECTOR'("00000000000000000000000000001111"); --F
dsocm_bram_BRAM_Dout_B_pin <= transport
std_logic_VECTOR'("00000000000000001111111111111111"); --FFFF
-1- Do i need to set as "external ports" the port B in the Data and
Instruction controllers?
-2- If yes then how i can load the address and the data trought the
ports?connect them with a common internal signal probably?
-3- Do i need to connect in an internal signal the
i.e.dsocm_bram_BRAM_Addr_B and isocm_bram_BRAM_Addr_B so they can have
the same address vector?
The other problem concerning the Assembly for that:
Also the address map is:
Address Map for Processor ppc405_0
(0b0000010000-0b0000010011) ppc405_0
(0b0000100000-0b0000100011) ppc405_0
(0x40000000-0x4000ffff) LEDs_16Bit plb->plb2opb->opb
(0x41c00000-0x41c0ffff) opb_timer_1 plb->plb2opb->opb
(0xa0e08000-0xa0e0ffff) docm_cntlr docm
(0xffff8000-0xffffffff) iocm_cntlr iocm
Checking ELFs associated with PPC405 instance ppc405_0 for overlap...
I would like the PPC405 to read data (word type 32 bits) from the
BRAM but i cannot understand using assembly code how to do it. i have
tried to load/read but
with no expectable result. Can u write the 3-4 lines using them as
a pattern form for the others?
thank you very much.
Article: 123741
Hello all:)
I am having a problem with the OCM BRAM. I am using virtex II pro and
EDK tools.
I have an OCM BRAM and the PORT B is unconnected. I would like to give
throught a testbench on PORT B data and address vectors. SO i have
done the Port
B of BRAM as "external signals". The question is that is makes two OCM
controllers, the one for Data (Docm_cntlr) and the other for
instruction (iocm_cntlr).
Part of the testbench:
WAIT FOR 30 ns; -- Time=930 ns
dsocm_bram_BRAM_Addr_B_pin <= transport
std_logic_VECTOR'("00000000000000000000000000001111"); --F
dsocm_bram_BRAM_Dout_B_pin <= transport
std_logic_VECTOR'("00000000000000001111111111111111"); --FFFF
-1- Do i need to set as "external ports" the port B in the Data and
Instruction controllers?
-2- If yes then how i can load the address and the data trought the
ports?connect them with a common internal signal probably?
-3- Do i need to connect in an internal signal the
i.e.dsocm_bram_BRAM_Addr_B and isocm_bram_BRAM_Addr_B so they can have
the same address vector?
The other problem concerning the Assembly for that:
Also the address map is:
Address Map for Processor ppc405_0
(0b0000010000-0b0000010011) ppc405_0
(0b0000100000-0b0000100011) ppc405_0
(0x40000000-0x4000ffff) LEDs_16Bit plb->plb2opb->opb
(0x41c00000-0x41c0ffff) opb_timer_1 plb->plb2opb->opb
(0xa0e08000-0xa0e0ffff) docm_cntlr docm
(0xffff8000-0xffffffff) iocm_cntlr iocm
Checking ELFs associated with PPC405 instance ppc405_0 for overlap...
I would like the PPC405 to read data (word type 32 bits) from the
BRAM but i cannot understand using assembly code how to do it. i have
tried to load/read but
with no expectable result. Can u write the 3-4 lines using them as
a pattern form for the others?
thank you very much.
Article: 123742"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message news:71fnd39ctb6egc7jjloldmvn9pjnr96u4s@4ax.com... > On Sun, 02 Sep 2007 22:38:38 GMT, "KJ" wrote: > >>For whatever tools that you have that meet the following two tests, did >>you >>open a service request? >>- Tool claims compliance to VHDL standard >>- Tool does not error (or at least warning) about ignoring the initial >>value >>assignment > > Every synth tool I've used issues a warning or error when it ignores > initial values. It's a tool restriction I've learnt to live with. If the target device does not support initial values then that would be the correct behaviour of the tool. If the target device does support a power up value for registers than I still say that the service request should be opened to the supplier for non-compliance to the VHDL standard. > On FPGAs with well-defined config values, I work around it by > providing an explicit asynchronous reset in the usual way and then > tying-off that reset to "false" somewhere in the top-level wrapper > that organises the design for the target platform. That gives me > no additional hardware cost in the FPGAs that I've used, and it > gives me a different, clumsier, but equally effective way to > specify initial values. But that doesn't sound like a 'tool' thing, it sounds like a way to make the code re-usable when targeted towards devices that either do or not support power up defined values. I thought your point had to do with grumblings about synthesis tools but it appears that it really has to do with physical parts that do not have guaranteed power up values. KJArticle: 123743
Sean, The other post on the subject is also appropriate: the signal integrity of whatever you do needs to be addressed, as the CCLK signal is not only an output to the SPI flash, the CCLK signal at the pin is also used internally (it is also an input). Also, there is a note that the CCLK always has a weak pullup, so even while tristate, the weak pullup is still there. AustinArticle: 123744
Andreas, Per the license agreement that one signs to get the software, 'reverse engineering' is a violation. Xilinx zealously protects its intellectual property through the means available to us. http://www.xilinx.com/ise/license/license_agreement.htm "3. Restrictions. To protect the Intellectual Property contained in the Software, you may not decompile, translate, reverse-engineer, disassemble, or otherwise reduce the Software, data files generated by the Software, and/or programmable hardware devices, transmit the Software or display the object code of the Software on any computer screen, or to make any hard-copy memory dumps of the object code. You may not, in whole or in part, modify or prepare derivative works of the Software. You may not publish or disclose the results of any benchmarking of the Software, or use such results for any other software development activities. You may not make any copies of the Software, except to the extent necessary to be used on separate non-simultaneous computers as permitted herein, and one (1) copy of the Software in machine-readable form solely for backup purposes." AustinArticle: 123745
> "3. Restrictions. To protect the Intellectual Property contained in the > Software, you may not decompile, translate, reverse-engineer, > disassemble, or otherwise reduce the Software, data files generated by > the Software, So you're not allowed to translate data files produced by the software. Sounds like no one can legally produce an bitstream then. Can I get a refund? JonArticle: 123746
austin wrote: > Sean, > > The other post on the subject is also appropriate: the signal integrity > of whatever you do needs to be addressed, as the CCLK signal is not only > an output to the SPI flash, the CCLK signal at the pin is also used > internally (it is also an input). > > Also, there is a note that the CCLK always has a weak pullup, so even > while tristate, the weak pullup is still there. Hyperlynx will tell. ;) I just noticed that it says the internal oscillator runs at about 50MHz, that's quite a lot faster than I expected... cu, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 123747
I was trying to estimate the power consumption of IGLOO AGL600V2 FPGA from Actel with IGLOO power calculator (posted on Actel website). I received very astonishing results. With full logic utilization at 50 MHz, 25% toggle rate and around 100 I/Os (LVCMOS 1.8V, LVCMOS 3.3V) it consumes around 100 mW. It's about half of Xilinx Coolrunner-II consumption and a small fraction of Xilinx FPGAs (Spartan or Virtex) for same functionality. I was very surprised by this so maybe I'm missing something here. Is anybody familiar with this chip and its power consumption?Article: 123748
Hi Andy,
1. I have a better solution to your complain:
"My comment regarding indentation, though poorly stated on my part,
was
intended to support the traditional use of indentation, which is to
visually indicate subordinate execution/analysis of statements. Since
orif is not executed subordinately to elsif any more than additional
elsif's are, it should not be indented beyond elsif. "
The better method to distinguish orif from elsif and that will
ultimately fend off any future tough questions about it is to put the
two keywords in two keyword listing tables in text editor's file and
they will be shown in two different colors, one RED, another PINK, as
TextPad, Emac, or any text editors do without conventional indent
practise change. It is a trivial thing, but exaggerated to a
disadvantage and failure at a strategic level.
2. I disagree with your following comment:
Now, if we are allowed to extend the standard (not the language),
with
the use of a synthesis-aware assertion and zero_one_hot() function,
this can be greatly simplified, while also making it more
functionally
clear:
process (reset, clk) is
begin
if reset = '1' then
outbus <= (others => '0');
elsif rising_edge(clk) then
for i in e'range loop
if e(i) = '1' then
outbus <= data(i);
exit;
end if;
end loop;
assert zero_one_hot(e); <-- useless and just waisting time !!!
end if;
end process;
With your above coding, it seems to me that you don't have a deep
insight why VHDL needs a mechanism to transfer mutually exclusive
information to VHDL compiler, neither does Jim.
With your coding, it doesn't need to provide the information the
assertion provides. It is a well known popular practise before
introducing mutually exclusiveness.
VHDL COMPILERS NEED MUTUALLY EXCLUSIVE INFORMATION IN ORDER TO KEEP
'IF...END IF' STATEMENT STRUCTURE UNIQUITOUS AND MAKE IT POSSIBLE
WRITING HARDWARE IS JUST LIKE WRITING SOFTWARE C (all if statement
when writing software).
We provide EXTRA mutually exclusive information to VHDL compiler and
let the compiler do better job with the "if...end if" statement
structure than what you and we have traditionally done. Because
"if...end if" statements are the simplest and unified way to express
logic ideas. Any advantages current hardware writing style (shown as
in your code) would dissapear and become unnecessary if mutually
exclusive information is given.
Why the above statement is waistful? You have already written the code
with the knowledge how it behaves and adding the assertion statement
just let simulator waisting time to do what you and I never do it
before. No assertion statement in your code works well and nobody adds
the assertion statements to confirm it now.
3. My opinion is when VHDL compilers get more information about
mutually
exclusive information, what you can do, the VHDL compilers can do
better.
VHDL compilers can generate all coding you showed for one level of
mutually exclusiveness. You may not write efficiently for code with
two levels or even three levels of mutually exclusiveness. Personal
power is limited and VHDL compilers can be trained to do more
mechanical things better than any human.
-- It is Jim's coding
OutBusA : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if (E0 or E1 or E2 or E3 or E4 or E5) = '1' then
OutBus <=
(E0 and Data0) or (E1 and Data1) or (E2 and Data2) or
(E3 and Data3) or (E4 and Data4) or (E5 and Data5) ;
end if ;
end if ;
end process;
-- It is my coding
A : process(RESET, CLK)
begin
if(RESET = '1') then
OutBus <= (others=>'0');
elsif rising_edge(CLK) then
if(E0 = '1') then
OutBus <= Data0;
orif(E1 = '1') then
OutBus <= Data1;
orif(E2 = '1') then
OutBus <= Data2;
orif(E3 = '1') then
OutBus <= Data3;
orif(E4 = '1') then
OutBus <= Data4;
orif(E5 = '1') then
OutBus <= Data5;
else
OutBus <= OutBus;
end if;
end if;
end process;
The above equation would be implemented in Xilinx chip with carry
chain with initial input data to the carry chain being OutBus. The
following enable equation would be eliminated from Jim's coding:
(E0 or E1 or E2 or E3 or E4 or E5) = '1'
It is not a LUT or two saving as some suggesed. For a up to 400MHz
project, every extra logic would kill a design. Because it takes more
route resources. When route resources exhausted, the running
frequency would drop dramatically and would kill a otherwise successfu
design.
LUT is less than a cent in a FPGA.
4. If you keep writing your coding style, you never need assertion
functions. If you write assertion function to declare a group of
signals are mutually exclusive, you must stick with the 'if' statement
structure to get its function working. Otherwise writing assertion,
like your code does, is just waisting time.
5. orif or other similar spelling OIF, _ORIF, is not replacable with
assertion function.
6, My another keyword method: Exclusive(or other name, no problem).
Here is an example how Exclusive is used:
signal A : unsigned(5 downto 0) ; -- to store mutually exclusive data
Exclusive : (A); -- it indicates that signal A of its bits is mutually
exclusive.
Exclusive : (StateRead, StateWrite); -- indicate two state machines
are mutually exclusive with their intial states being common. This
function extends mutually exclusive funtion to more than 2 state
machines.
If you need, I can send my paper to you: "HDL Code Inefficiency
Sources and Its Solutions".
Jim,
I am going to publish 6 articles in a batch within next 6 months in
one of three forms: websites, patent applications or international
conferences. One of them has a very good example how 'orif' is used, a
brand new usage. No special report to you is under consideration until
you are pursuaded in advance. You may have to wait for next 6 months
to get the files.
Weng
Article: 123749As I can see you have three interrupt sources but PARAMETER C_NUM_INTR_INPUTS = 2 Better delete this line, it will be "Auto Computed". Then your memory runs at 66MHz (and might pass the tests) but according to the datasheet you need at least 75MHz to run it properly. My advice is to try building the system for 50MHz. You'll get the dcm's configured to run the mem at 100MHz. Then use the ref design to tune it for 66/133 BR
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