Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

a logic to detect FPGA family?

Status
Not open for further replies.

Port Map

Advanced Member level 4
Joined
Aug 24, 2013
Messages
118
Helped
15
Reputation
30
Reaction score
14
Trophy points
1,298
Activity points
2,089
Hi,
I want to know is it possible to find current FPGA family with a logic inside FPGA?
I know some about ID CODE in Xilinx FPGAs, is it possible to read it inside FPGA for this purpose?

My question is about both Altera and Xilinx FPGAs!
 

Just wondering why it would be relevant? You would have to recompile the code for each different chip due to different architectures, pinouts etc. So what are you trying to do with the chip? I don't think chip info is available inside.
 

This could be relevant if you are a 3rd party IP vendor that licenses IP per device. The dev might not know anything about licensing and might use the IP on all future designs without paying for it. Being able to determine the device would allow you to expose a license error output port and hold the IP in a safe reset state. At that point the dev would need to ether pay for the correct license, or reverse engineer the IP to remove the reset.

For Xilinx, you can use ICAP to read the IDCODE register. See the configuration user guide for this. I'm not sure if you can use the same primitive for all devices -- you might require a generic or parameter for device family and vendor.
 
I had come across a design where an 7-series Xilinx FPGA was being controlled by an ARM core. The ARM core naturally had access to the status and config registers of 7-series Xilinx FPGA. One of the read-only config regs of the FPGA was being set by a 32 bit constant (at the top-level) that carried info on the FPGA being used, something like shown below:

Code:
 -- Generic at top-level
DESIGN_RELEASE_TYPE             : unsigned(7 downto 0)   := to_unsigned(  0, 8); 
DESIGN_RELEASE_MAJOR          : unsigned(7 downto 0)   := to_unsigned(  0, 8); 
DESIGN_RELEASE_MINOR          : unsigned(7 downto 0)   := to_unsigned(  1, 8)

-- Signal declarations area
constant FPGA_DESIGN_VERSION  : unsigned(31 downto 0) := x"A7" & DESIGN_RELEASE_TYPE & DESIGN_RELEASE_MAJOR & DESIGN_RELEASE_MINOR;
signal fpga_design_version_s        : std_logic_vector(31 downto 0):= std_logic_vector(FPGA_DESIGN_VERSION);

 -- Portmap area
.
.
fpga_design_version_i => fpga_design_version_s ,
.
.

In this way, the Linux running on the ARM can always read the reg and have info about the hardware running on FPGA. You see only the hardware engineer can change these parameters and generate a new bitstream as needed.
 

In my designs, I would include a BRAM that stored a compressed text file. The contents would be loaded using data2mem after the build had completed. This allowed me to store a register map with names to addresses as well as the build time, build user, timing score, etc...
 

thanks for all replies.
Storing information in FPGA by myself(like registers or ROMs) is not the case I'm looking for. I want an automatic method.

I thing ICAP could be a solution.
 

If you control the FPGA and build flow, you should use something other than ICAP. If you don't, ICAP might work. However this approach is not ideal as ICAP is a unique resource and means you are taking control of it. Any ICAP interface should have a request-grant system to allow ICAP to be used by the end developer. There might also be other issues with this /wrt secured devices. I wasn't able to find out how to do this on altera. My guess is that it is similar as the underlying mechanism is part of JTAG and probably works even if it isn't documented.
 

As far as I know, Altera FPGAs don't provide a feature similar to ICAP.
 

I suspect they do, but just don't document it. I suspect the partial reconfiguration IP also can access JTAG exposed information. I also suspect that you could get to IDCODE using a similar process as Xilinx as it probably requires effort to block this from internal logic vs jtag. That said, I have no idea if this is actually true and if the OP can't find documentation for this it should not be relied upon.

That said, it would be terrible to try to sell IP that requires a license for a different, over-complicating feature the end-dev doesn't care about that also affects their development flow and imposes a burden that encourages them to reverse engineer your IP instead of just pay for it.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top