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
Let's not quibble over the price tag, and whether $10,000 is a meaningful hurdle. The debate was about key security, and the consensus in the crypto community is that things like efuses can be read out with moderate effort, while battery-backed up SRAM data is either much more secure or even perfectly secure, i.e. has never been cracked. Some people think batteries are a pain, others think they are just fine and last >15 years. It's security vs convenience. Xilinx picked security, Altera picked convenience. The choice is yours. Peter Alfke, Xilinx ApplicationsArticle: 104451
mk wrote:
> In your code, I didn't see any decoding of the top 3 bits to enable
> one of the 8 rams to cover the whole 64k range. That's the reason it
> thinks all the memories are identical, you are using the same 13 bits
> to drive them. You should somehow differentiate them, probably with an
> enable signal generated from the top 3 bits (maybe you're doing that
> during the generation of read/write strobe?). Why it's removing the
> last 8k memory I am not sure as you are certainly driving the inputs;
> check the top level connectivity for reading the outputs of the memory
> into the core.
One moment I thought You had it, but alas.
To remove any doubt I used all 16 address bits in the decoding as in:
int_ram_adr <= ram_adr_i(12 downto 0);
p_read : process (clk)
begin
if rising_edge(clk) then
if ram_adr_i(15 downto 13) = "000" then
ram_data_o <= extram(conv_integer(int_ram_adr));
else
ram_data_o <= "00000000";
end if;
end if;
end process p_read;
But apart from less warnings nothing changed.
Sietse
Article: 104452Peter Alfke wrote: > Let's not quibble over the price tag, and whether $10,000 is a > meaningful hurdle. > > The debate was about key security, and the consensus in the crypto > community is that things like efuses can be read out with moderate > effort, while battery-backed up SRAM data is either much more secure or > even perfectly secure, i.e. has never been cracked. > > Some people think batteries are a pain, others think they are just fine > and last >15 years. > > It's security vs convenience. Xilinx picked security, Altera picked > convenience. > The choice is yours. > Peter Alfke, Xilinx Applications > Any security system must be convenient, or it won't be used. A hefty proportion of windows users have firewall software that came with their machines, but it's turned off - simply because it is too inconvenient. When it's enabled, the firewall keeps asking these daft questions about whether your programs are allowed to do this or that - it's far easier just to turn the stupid thing off. An advanced application level software firewall may theoretically be more secure than a simple "incoming bad, outgoing good" firewall, but it's no help if people don't use it. The same thing probably applies here. I've no experience with either Altera's or Xilinx's solutions, but I can understand the principle that it's possible to read out efuses but not sram bits. If Altera's solution is more convenient, then perhaps it is more secure in that developers are more likely to use it? After all, all they need to do is choose some options in the software - there is no need to add batteries to the card, and to handle the support costs of dealing with lost keys (users are so imaginative - "I took out the battery to make sure the card got a proper reset"). As to how secure Altera's solution is - the Altera guys are not idiots, and it is unbecoming of you to them as such. Sure, it's possible to read out the efuses in theory, but my guess is you're going to have to do a lot more than just a couple of $5000 rounds. I'm sure there are theoretical methods of breaking Xilinx's security too, such as probing the bit stream out of the decoder. Since you have to get access to the device while power is on, it's going to be difficult - but I'm sure it can be done given enough time and money (and boards to practise on). To be secure, all a method has to do is raise the stakes high enough that alternative methods are cheaper - once it is easer and cheaper to bribe the original engineers for a copy of the code, the device is secure enough.Article: 104453
> After designing the Aurora protocol and implementing it, I want to > access the data values using my PC. I am not really sure what you are trying to do. Are you trying to route the output of the transceiver to a RS232 UART? If so, even if you managed to do so, it wouldn't be very useful; there's no way multi-gigabit data rates can be sustained over RS232 (or multi-megabit, for that matter!). Are you trying to send data values to both the MGT and to the RS232 UART? If so, you will have to deal with the difference in speed between the two. However, if you can live with that that, coding a UART in HDL isn't too hard. - NathanArticle: 104454
David Brown wrote: > > > As to how secure Altera's solution is - the Altera guys are not idiots, > and it is unbecoming of you to them as such. David, you should be ashamed of yourself for that dumb statement. I did the opposite, I confirmed earlier that they desigend their logic and algorithm correctly, and explained then that they chose a different optimization, convenience over security. To tell me what is "unbecoming" is a baseless insult. Peter AlfkeArticle: 104455
actually I just need to transmit the values on RS232 UART core. I am not too bothered about the speed. I just want the values on the PC. most of the RS232 UART cores(atleast the one on the opencores.org site and one referenced by the HERON IP ) do not tell how the data is visible in the terminal program. I have now two VHDL projects of the RS232 but they don't work at least I don't see any data on the terminal window. So I am now considering sending the data to the PPC that will in turn send it to the RS232 UART core.. Lemme know if anyone has had similar problems. Thanks, Vivek Nathan Bialke wrote: > > After designing the Aurora protocol and implementing it, I want to > > access the data values using my PC. > > I am not really sure what you are trying to do. Are you trying to route > the output of the transceiver to a RS232 UART? If so, even if you > managed to do so, it wouldn't be very useful; there's no way > multi-gigabit data rates can be sustained over RS232 (or multi-megabit, > for that matter!). Are you trying to send data values to both the MGT > and to the RS232 UART? If so, you will have to deal with the difference > in speed between the two. However, if you can live with that that, > coding a UART in HDL isn't too hard. > > - NathanArticle: 104456
Vivek Menon wrote: > actually I just need to transmit the values on RS232 UART core. I am > not too bothered about the speed. I just want the values on the PC. > most of the RS232 UART cores(atleast the one on the opencores.org site > and one referenced by the HERON IP ) do not tell how the data is > visible in the terminal program. I have now two VHDL projects of the > RS232 but they don't work at least I don't see any data on the terminal > window. You likely will need to convert the data to ASCII, if you want it to show up on a terminal. That is quite easy to do.Article: 104457
No wonder the screen was blank..!!! Duane Clark wrote: > Vivek Menon wrote: > > actually I just need to transmit the values on RS232 UART core. I am > > not too bothered about the speed. I just want the values on the PC. > > most of the RS232 UART cores(atleast the one on the opencores.org site > > and one referenced by the HERON IP ) do not tell how the data is > > visible in the terminal program. I have now two VHDL projects of the > > RS232 but they don't work at least I don't see any data on the terminal > > window. > > You likely will need to convert the data to ASCII, if you want it to > show up on a terminal. That is quite easy to do.Article: 104458
David, Would you email me directly? I'd like to send you the photomicrograph of a fuse that is a 1, and a 0. Austin David Brown wrote: > Peter Alfke wrote: >> Let's not quibble over the price tag, and whether $10,000 is a >> meaningful hurdle. >> >> The debate was about key security, and the consensus in the crypto >> community is that things like efuses can be read out with moderate >> effort, while battery-backed up SRAM data is either much more secure or >> even perfectly secure, i.e. has never been cracked. >> >> Some people think batteries are a pain, others think they are just fine >> and last >15 years. >> >> It's security vs convenience. Xilinx picked security, Altera picked >> convenience. >> The choice is yours. Peter Alfke, Xilinx Applications >> > > Any security system must be convenient, or it won't be used. A hefty > proportion of windows users have firewall software that came with their > machines, but it's turned off - simply because it is too inconvenient. > When it's enabled, the firewall keeps asking these daft questions about > whether your programs are allowed to do this or that - it's far easier > just to turn the stupid thing off. An advanced application level > software firewall may theoretically be more secure than a simple > "incoming bad, outgoing good" firewall, but it's no help if people don't > use it. > > The same thing probably applies here. I've no experience with either > Altera's or Xilinx's solutions, but I can understand the principle that > it's possible to read out efuses but not sram bits. If Altera's > solution is more convenient, then perhaps it is more secure in that > developers are more likely to use it? After all, all they need to do is > choose some options in the software - there is no need to add batteries > to the card, and to handle the support costs of dealing with lost keys > (users are so imaginative - "I took out the battery to make sure the > card got a proper reset"). > > As to how secure Altera's solution is - the Altera guys are not idiots, > and it is unbecoming of you to them as such. Sure, it's possible to > read out the efuses in theory, but my guess is you're going to have to > do a lot more than just a couple of $5000 rounds. I'm sure there are > theoretical methods of breaking Xilinx's security too, such as probing > the bit stream out of the decoder. Since you have to get access to the > device while power is on, it's going to be difficult - but I'm sure it > can be done given enough time and money (and boards to practise on). To > be secure, all a method has to do is raise the stakes high enough that > alternative methods are cheaper - once it is easer and cheaper to bribe > the original engineers for a copy of the code, the device is secure enough.Article: 104459
does anybody have a function or package that converts data into ASCII?? Vivek Menon wrote: > No wonder the screen was blank..!!! > Duane Clark wrote: > > Vivek Menon wrote: > > > actually I just need to transmit the values on RS232 UART core. I am > > > not too bothered about the speed. I just want the values on the PC. > > > most of the RS232 UART cores(atleast the one on the opencores.org site > > > and one referenced by the HERON IP ) do not tell how the data is > > > visible in the terminal program. I have now two VHDL projects of the > > > RS232 but they don't work at least I don't see any data on the terminal > > > window. > > > > You likely will need to convert the data to ASCII, if you want it to > > show up on a terminal. That is quite easy to do.Article: 104460
David, As to convenience, place a lithium coin cell on the pcb per the app note. Ask the software to generate a random key for you (or pick one yourself), send the key to the JTAG port. Verify the key can be written and read, then write it in secure mode (so it can not be read out again without it being erased immediately). Program eeprom or other memory with encrypted bitstream. Done. Not sure about Altera, as they have now told us they keep secrets from even their customers, and you have to sign an NDA. But, in theory, you get a key (does their software generate random 128 bit keys? Let us suppose it does), program the part (How? It is a secret! But let us imagine it is as simple as JTAG), an then place encrypted design in the memory. Done. So, we have one more step: make sure their is a lithium coin cell on the pcb connected to the Vbatt pin. That is the total level of inconvenience we offer. The benefit is that we offer all four levels of security in FIPS 140-2 compliance, and Altera offers no level of compliance at all with FIPS 140-2. What is so important about FIPS 140-2? It is the required security standard for the US Federal government, as well as for banks, networks, and others who are serious about security. Don't need FIPS 140-2? Then go ahead and use efuse keys. But also be aware of the risks. As for reverse engineering, I can send you presentations of how efuse technology smart cards are reverse engineered (hacked). It is a junior level EE project at most universities now. Austin David Brown wrote: > Peter Alfke wrote: >> Let's not quibble over the price tag, and whether $10,000 is a >> meaningful hurdle. >> >> The debate was about key security, and the consensus in the crypto >> community is that things like efuses can be read out with moderate >> effort, while battery-backed up SRAM data is either much more secure or >> even perfectly secure, i.e. has never been cracked. >> >> Some people think batteries are a pain, others think they are just fine >> and last >15 years. >> >> It's security vs convenience. Xilinx picked security, Altera picked >> convenience. >> The choice is yours. Peter Alfke, Xilinx Applications >> > > Any security system must be convenient, or it won't be used. A hefty > proportion of windows users have firewall software that came with their > machines, but it's turned off - simply because it is too inconvenient. > When it's enabled, the firewall keeps asking these daft questions about > whether your programs are allowed to do this or that - it's far easier > just to turn the stupid thing off. An advanced application level > software firewall may theoretically be more secure than a simple > "incoming bad, outgoing good" firewall, but it's no help if people don't > use it. > > The same thing probably applies here. I've no experience with either > Altera's or Xilinx's solutions, but I can understand the principle that > it's possible to read out efuses but not sram bits. If Altera's > solution is more convenient, then perhaps it is more secure in that > developers are more likely to use it? After all, all they need to do is > choose some options in the software - there is no need to add batteries > to the card, and to handle the support costs of dealing with lost keys > (users are so imaginative - "I took out the battery to make sure the > card got a proper reset"). > > As to how secure Altera's solution is - the Altera guys are not idiots, > and it is unbecoming of you to them as such. Sure, it's possible to > read out the efuses in theory, but my guess is you're going to have to > do a lot more than just a couple of $5000 rounds. I'm sure there are > theoretical methods of breaking Xilinx's security too, such as probing > the bit stream out of the decoder. Since you have to get access to the > device while power is on, it's going to be difficult - but I'm sure it > can be done given enough time and money (and boards to practise on). To > be secure, all a method has to do is raise the stakes high enough that > alternative methods are cheaper - once it is easer and cheaper to bribe > the original engineers for a copy of the code, the device is secure enough.Article: 104461
Hi, I read some books describing that preservation of patent ideas through a notary is valid in the law. Yesterday we put all patent materials into a large envelop and went to a notary to seal it. A lawyer in the notary put notary stamps on all papers and sealed the envelop properly with stamps too. What surprised us is there is no date!!! There are no date stamps like a register letter that must have a date stamp on the envelop. There is no receipt neither. What does It prove? What I need is a date a patent law court admits. But here there is no date. What is wrong? What should I do next? Thank you. WengArticle: 104462
Thanks for everyones comments. Anyone have any suggestions on getting started monkeying around with RAM controllers? I didn't have picoblaze in mind for a specific task, rather just playing around getting my feet wet. I would like to work with a basic setup to start out. Load program data from RAM, and then advance into modifying a controller to decrypt data as it brings it it. Anyone have any good starting points to "ease" me into this world. Implementing a RAM controller tutorial... Thanks Jim Granville wrote: > karrelsj wrote: > > Hello. > > > > I just started looking at Picoblaze. Has anyone completed a Picoblaze > > and DDR RAM implementation? Or does anyone have any strong opinions on > > this issue. My main goal is to store program data on RAM and access it > > with Picoblaze. I see OpenCores has a DDR/SDRAM controller... > > > > Thanks for your constructive ideas. > > Do you mean a large data-space in DDR, and that the PicoBlaze runs from > Block Ram in the FPGA ? > That would be do-able, and you could add features like the Serial FLASH > devices have, which is auto-inc of Rd/Wr address, for continual access. > ( that saves a lot of address thrashing ) > > If you needed more code, two bock RAMS, with reload-flip support in > the FPGA, would allow the DDR behave like a HardDisk (from > the code perspective). > > What split and sizes do you need for Code/data ? > > -jgArticle: 104463
Vivek Menon wrote: > does anybody have a function or package that converts data into ASCII?? You send one nibble (4 bits) at a time. If the nibble is between 0-9, then add 0x30 (hex 30). If between a-f, add 0x60. It should be easy to figure out how to do that in VHDL/Verilog. That will give you a hex display.Article: 104464
We are specialize in the supply, installation, commissioning and servicing of a range of industrial X-Ray Inspection System for the electronics/semiconductor industries PCB MLB : Inspect the drill hole PCB panels : Excessive solder, insufficient solder, misalignment, and void BGA : Bridge/Short, excessive solder, insufficient solder CSP : Deformity Filp Chip : Bridge/ Short Lithium ion battery : Bridge/ Short. . welcome to contact us: email: zhanglingmu@gmail.com Tel: (65)93887563 315 Outram Road Tan Boon Liat Building Singapore 169074Article: 104465
Kolja Sulimma wrote: > Fred schrieb: > > Does anyone know of any software, ideally freeware, which can use the above > > JTAG interfaces to exercise other JTAG interfaces on non FPGA devices? > > > > In my case I'd like to read the state of pins on an unrelated device. > > There is JTAG code in the not very active open source project "open wince". > > Kolja I use http://www.intellitech.com/products/schematiclogicprobe.asp which lets me toggle pins with a view of the schematic - if netlist avaialble.. It works both with Xilynx Pciii/pc4 and altera byteblaster (no USB though). they have all the FPGA device JTAG files (bsdl) in their libraries. you can get a 90 day eval license and I just renew the eval license. They don't seem to care, i've renewed six times. I think they are interested in bigger fish and not their main business. KimArticle: 104466
I have been reading everyone's comments on how to setup a Master Read,
but I have hit a wall. I can make the Read Request, but nothing seems
to happen after that. I never get a write request to my slave.
I am asserting these signals in my master:
IP2Bus_MstRdReq <= '1';
IP2Bus_Addr <= mst_ip2bus_addr;
IP2IP_Addr <= mst_ip2ip_addr;
IP2Bus_MstNum <= "00001";
master_ns <= read_ddr;
* Where mst_ip2bus_addr and mst_1p2ip_addr are set in the slave state
machine. Any known bugs with the PLB IPIF or things people maybe did
to get around this issue? Thanks.
Article: 104467I have added some notes to www.fpgaarcade.com describing how to modify the Spartan kit board to have 12 bit RGB output on the VGA port. Also included is some test pattern code / bitfile to produce some output. /MikeJArticle: 104468
>I'm doing few tests in these days with the PicoBlaze and it seems to >work just fine. Now, in my project, where a Spartan3 has to deal with a >DSP through a serial spi-like communication to reply on different >request that may arrive, do you think could be woth using with a >PicoBlaze as a supervisor? I mean, the FPGA could reveive a request to >read from its inputs, or to write on its output, or to read a >temperature from an spi-sensor and the send it to the DPS, or to read >the values from quadraure decoder... >Picoblaze or vhdl from scratch in your experienced opinion? >I'm making some considerations by myself now, but I'd like to hear >comments from you too. In general, if you can easily turn a hardware problem into software, that's probably the right thing to do. How many states will your system have? Will a circles and arrows drawing of your state machine fit on a page? For anything bigger than a page, I try hard to turn it into software. I find it much easier to deal with a complicated problem when thinking of it as software. Do you have lots of multi way branches? Do you have enough time to turn them into a chain of two way branches? ... The main disadvantage of using software is that you have to setup and maintain a software development environment in addition to your FPGA environment. That's usually a lot easier after you have done it the first time. Another answer is to do (or try) both and see which one you like better. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 104469
We have a XC2VP40 with 98% silce utilization. The System contains a PPC405 300 MHz with PLB 100 Mhz and OPB 50 Mhz. On PLB side we have - plb sdram - plb emac - plb bram - plb dma ctrl ( own core) - plb user core 1 ( own core ) - plb user core 2 ( own core ) And i do not have any timing problems with ISE 8.1 and EDK 8.1. The flow needs quit a "long" time. But in the end i have (0) timing errors without planahead. AndiArticle: 104470
Peter Alfke wrote: > David Brown wrote: >> As to how secure Altera's solution is - the Altera guys are not idiots, >> and it is unbecoming of you to them as such. > > David, you should be ashamed of yourself for that dumb statement. > I did the opposite, I confirmed earlier that they desigend their logic > and algorithm correctly, and explained then that they chose a different > optimization, convenience over security. > > To tell me what is "unbecoming" is a baseless insult. > Peter Alfke > I apologise for being insulting - that was not my intention. I felt your earlier reply to Dave Greenfield, including "Yes, Altera can do logic design. Bravo! Advance to second grade!", was intentionally patronising, and lowering the tone of the thread (which is interesting). Unfortunately, the context of that post was dropped from the thread (by you), so my comment appeared out of the blue - I should have made it in an appropriate branch. And yes, I did read your other comments on the two security solutions - it was the contrast between your normal technical, informative and (reasonably) objective comments and that sarcastic dig at Dave Greenfield and Altera that annoyed me.Article: 104471
Austin Lesea wrote: > David, > > As to convenience, place a lithium coin cell on the pcb per the app > note. Ask the software to generate a random key for you (or pick one > yourself), send the key to the JTAG port. Verify the key can be written > and read, then write it in secure mode (so it can not be read out again > without it being erased immediately). Program eeprom or other memory > with encrypted bitstream. > > Done. > > Not sure about Altera, as they have now told us they keep secrets from > even their customers, and you have to sign an NDA. But, in theory, you > get a key (does their software generate random 128 bit keys? Let us > suppose it does), program the part (How? It is a secret! But let us > imagine it is as simple as JTAG), an then place encrypted design in the > memory. > > Done. > > So, we have one more step: make sure their is a lithium coin cell on > the pcb connected to the Vbatt pin. > > That is the total level of inconvenience we offer. > Peter Alfke referred to Altera's solution as being more biased towards convenience, while Xilinx's was more biased towards security. Since Peter knows a great deal more than me about both security systems, I assume that the difference in convenience is relevant (unless, of course, he was referring to convenience for Altera rather than for the customer). At the moment, and for the foreseeable future, I am not using either Altera or Xilinx's bigger devices, and I am not overly concerned about security. And I'm sure that if I did need such a design, then the inconvenience of having a battery would not stop me using Xilinx - other factors are more important. > The benefit is that we offer all four levels of security in FIPS 140-2 > compliance, and Altera offers no level of compliance at all with FIPS 140-2. > > What is so important about FIPS 140-2? It is the required security > standard for the US Federal government, as well as for banks, networks, > and others who are serious about security. > > Don't need FIPS 140-2? Then go ahead and use efuse keys. But also be > aware of the risks. > The risks must be balanced, and it's important to know them (I don't, obviously, but I've never needed to know). What's important is to protect the IP, which means increasing the costs until it is impractical for someone to steal it. You don't need a zero risk solution, you need something with a risk that is known to be low enough. I presume that Altera will give customers more detailed information when necessary - although I think the Xilinx-style openness is better. > As for reverse engineering, I can send you presentations of how efuse > technology smart cards are reverse engineered (hacked). It is a junior > level EE project at most universities now. > I'm following this thread out of interest, and not from a need of detailed knowledge. If you have public links of interest to others here, post them here - others have questioned the accuracy of your numbers and might like to see examples. It would of course be interesting to hear Altera's viewpoint as well. As for sending anything directly to me - I appreciate the offer, but there is no need, and it would be a waste of your time. Newsgroup posts benefit more people. mvh., David > Austin > > > David Brown wrote: >> Peter Alfke wrote: >>> Let's not quibble over the price tag, and whether $10,000 is a >>> meaningful hurdle. >>> >>> The debate was about key security, and the consensus in the crypto >>> community is that things like efuses can be read out with moderate >>> effort, while battery-backed up SRAM data is either much more secure or >>> even perfectly secure, i.e. has never been cracked. >>> >>> Some people think batteries are a pain, others think they are just fine >>> and last >15 years. >>> >>> It's security vs convenience. Xilinx picked security, Altera picked >>> convenience. >>> The choice is yours. Peter Alfke, Xilinx Applications >>> >> Any security system must be convenient, or it won't be used. A hefty >> proportion of windows users have firewall software that came with their >> machines, but it's turned off - simply because it is too inconvenient. >> When it's enabled, the firewall keeps asking these daft questions about >> whether your programs are allowed to do this or that - it's far easier >> just to turn the stupid thing off. An advanced application level >> software firewall may theoretically be more secure than a simple >> "incoming bad, outgoing good" firewall, but it's no help if people don't >> use it. >> >> The same thing probably applies here. I've no experience with either >> Altera's or Xilinx's solutions, but I can understand the principle that >> it's possible to read out efuses but not sram bits. If Altera's >> solution is more convenient, then perhaps it is more secure in that >> developers are more likely to use it? After all, all they need to do is >> choose some options in the software - there is no need to add batteries >> to the card, and to handle the support costs of dealing with lost keys >> (users are so imaginative - "I took out the battery to make sure the >> card got a proper reset"). >> >> As to how secure Altera's solution is - the Altera guys are not idiots, >> and it is unbecoming of you to them as such. Sure, it's possible to >> read out the efuses in theory, but my guess is you're going to have to >> do a lot more than just a couple of $5000 rounds. I'm sure there are >> theoretical methods of breaking Xilinx's security too, such as probing >> the bit stream out of the decoder. Since you have to get access to the >> device while power is on, it's going to be difficult - but I'm sure it >> can be done given enough time and money (and boards to practise on). To >> be secure, all a method has to do is raise the stakes high enough that >> alternative methods are cheaper - once it is easer and cheaper to bribe >> the original engineers for a copy of the code, the device is secure enough.Article: 104472
Sietse,,
you are right my mystake, 13 address lines makes 8K locations (sorry for
the confusion)
anyway I synthesized your original code with ISE8.2 and works fine for me.
Device utilization summary:
---------------------------
Selected Device : 3s100evq100-5
Number of Slices: 0 out of 960 0%
Number of IOs: 35
Number of bonded IOBs: 31 out of 66 46%
Number of BRAMs: 4 out of 4 100%
Number of GCLKs: 1 out of 24 4%
____________________
Can you please run XST for this file only (in isolation) to see if you
get the expected results
Aurelian
Sietse Achterop wrote:
> Aurelian Lazarut wrote:
>
>> to be more precise you have:
>> int_ram_adr <= ram_adr_i(12 downto 0);
>>
>> what about ram_adr_i(15 downto 13) who's driving them ?
>>
>> Aurash
>>
>> Aurelian Lazarut wrote:
>>
>>> you have a 8K memory but it seems from the log file that you are not
>>> using the all the address bits,
>>> WARNING:Xst:647 - Input <ram_adr_i<15:13>> is never used.
>>> which means that you basically need only 1K from the total of 8K and
>>> XST remove the rest, I think this make sense if you keep these
>>> addresses tied to a constant.
>>> Aurash
>>
>
> Hello Aurash,
>
> thanks for the prompt reply.
> (the 8KB memory serves as the external RAM of the 8051)
> But 8 KByte uses 13 address bits, so that's ok. The 8051 cpu has 16
> address bits and only 13 bits for the lower 8 KB are used.
> Or better, the 8KB is repeated 8 times in the 64KB address space.
> So all 13 address lines for the RAM are used, and I don't see why
> it is optimized away.
>
> Sietse
--
__
/ /\/\ Aurelian Lazarut
\ \ / System Verification Engineer
/ / \ Xilinx Ireland
\_\/\/
phone: 353 01 4032639
fax: 353 01 4640324
Article: 104473Hi, Is there is any one who can help me in the SDK.Is it possible to modify the sdk generated code? regards subin subint wrote: > Hi, > I am using the platform studio first time.I like to know how i can add > my testbenches and remove the microblaze processor from the setup. > I am trying to generate the controller for my V4MB lx60 board > and i want to test the ddr in the board.From the tool(platform studio) > i can select the pheripherals and the processor etc but didnt have any > idea how can i use this to test my ddr.I tried to generate the hdl > code.But all the controllers are ipcores(black box) and i wont be able > to synthesize it using xilinx ise(library for these ipcores are > missing). > regards > subinArticle: 104474
You don't say where you had your documents notarized, but I know that when I get a document notarized in New Hampshire, the notary enters the description in a log book, which certainly has dates. I would suggest that you enter a date next to your signature yourself when the documents are notarized. The notary stamp indicates that the signing and dating was witnessed by a reliable person and a record kept of this witnessing. HTH Gabor Weng Tianxiang wrote: > Hi, > I read some books describing that preservation of patent ideas through > a notary is valid in the law. > > Yesterday we put all patent materials into a large envelop and went to > a notary to seal it. A lawyer in the notary put notary stamps on all > papers and sealed the envelop properly with stamps too. What surprised > us is there is no date!!! There are no date stamps like a register > letter that must have a date stamp on the envelop. There is no receipt > neither. > > What does It prove? What I need is a date a patent law court admits. > But here there is no date. What is wrong? What should I do next? > > Thank you. > > Weng
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