In my most recent column, we discussed the third-party IP core vendor's experience (or lack thereof). As usual, an interesting discussion ensued, and this provided a good opportunity to share our experiences. Let's proceed to the next question in our 10 Commandments.
No. 5: Can you show me your portfolio?
As you will doubtless (or, should I say, hopefully) recall from my earlier blogs, my colleagues and I have tried to share our experiences with third-party IP cores. Thanks to your comments and opinions, a few interesting motifs have appeared. One was posted by Myplanet: "We used to collect user cases, references, and experience through the IP provider." I think this provides a good basis for our discussions in this column.
Third-party IP vendors should be happy to share their portfolios.
In today's digital world, customers expect new products that provide more functionality and better performance at a lower price than their predecessors. We all can agree that the two main factors in every project are the design complexity and the cost. Even though design complexity is always increasing, we need to reduce both development costs and time to market.
The reuse of modules or IP blocks seems to be the most sustainable solution that meets these requirements. Building everything from scratch is a long and risky road to walk alone. You might say, "I can do everything on my own." Of course, you can, but will you be able to do this in a cost-effective and timely manner while adding any required extras to the final design? Reusing modules and functionalities, in the form of intellectual property, is very often the most reliable and cost-effective way to go.
Moreover, in many cases, licensing external IP cores can bring numerous bonuses for the designer and the company. When you go for a microcontroller like the 8051 (yes, I do love eight-bit machines), you can typically obtain a bunch of peripherals for free or almost free. One of our IP cores, the DP8051 (please forgive my product placement here) can be augmented with a USB combo pack (Audio, HID, or MS). The USB trio is not free, but when the system's total cost is taken into account, it is much lower than the cost of a standalone IP core.
In addition, a bundle like this saves designers huge amounts of time, because they don't need to struggle putting all the pieces of the puzzle together. When a company purchases a license for an IP core, it should receive everything required to design, test, and utilize that core in its own product.
@JezmoSSL And the next step was to define Visual C# OOP classes for memory blocks and the combinational logic, tie it together using get/set property accessors that are analogous to continuous assignments in Verilog. The memory classes have din methods to remember the values to be assigned by the launch methods and I have a cycle simulator that runs in Visual Studio with all its OOP debug capability.
Sometimes it seems that the level of abstraction makes it difficult to debug my own design.
@Hamster: With Quartus you can open the design file(which is HDL), Modify then create a new block symbol file. Yes it is kind of like the chicken and egg initially, but if you have an idea of the basic block function -- at least inputs/outputs -- start with HDL and connect the external lines graphically. I think Quartus then uses the HDL to create the block interconnects so the block diagram is just a graphic view of the HDL.
Since the blocks are created from HDL and I think it is possible to create a top level block for the block schematic which would also have an HDL design file so there is probably a way to have source control over the HDL and also to have the block graphics.
My current design has a few memory blocks, an HDL ALU, and an HDL module of combinatorial logic. The memory blocks were created by MegaWizard and the other 2 blocks are Verilog. Bus and control signal lines are drawn in where desired or just connected by name(properties) to reduce clutter. So my custom blocks originated as Verilog and the block schematic has the graphic view.
To change/modify a block, open the design file and edit the HDL rather than try to zoom and edit graphically. I have not attempted to create an heirarchy of schematics so am not sure if it can be done.
I've only used the schematic tool from Xilinx's ISE, but the problem I have is that unlike using pen and paper I haven not found a way to an empty box, draw lines into it, and then zoom in on the empty box and design its content.
This makes top down design hard with the schematic tool, and designing from the bottom up is hard unless you already have some sort of design planned out.
With HDLs I can bounce around like a Jack Russel before a walk.
@Jacek: "I can just add that I would suggest to start designing the FPGA using the FPGA Vendor's schematic tool. When using schematic tools, designing the FPGA content with embedded CPU doesn't differ a lot, from the typical application design using standard components and PCB."
This is very sound advice. The problem always becomes that the discussion always gets hi-jacked and becomes centered around coding styles and inference. BUT to explain concepts and ideas the first thing asked for is a block diagram. So it makes sense to start with a block diagram and enhance it as the design progresses. That does not mean that schematic entry is used for RTL level, but the block symbols on Quartus block diagrams are generated from an HDL design file that can be opened to expose the HDL. Another important thing is the block connections can be made visible or simply named as properties of the block.
A well designed block diagram that has functional names for blocks , busses, and nets is universally understood whereas Verilog and VHDL designers have a huge communications gap.
Duane Benson 2/8/2013 12:21:38 PM User Rank Blogger
Re: A rookie view
Jacek - re: "I meant that every IP Core we offer, has got its own specification, but when a customer tells us what he/she exact needs - we're tailoring our core to his/her needs" I applaud you for this. It's makes a customer's life a whole lot easier.
Duane Benson 2/8/2013 12:19:47 PM User Rank Blogger
Re: A rookie view
Jacek, Rfindley - This is very good information. It makes sense now and I don't feel so intimidated by the concept as I did. Right now, I'm jumping into simulation and VHDL, but I think I can give an embedded CPU a try right after that.
And re the second part... rfindley thanks a lot for your help :) I can just add that I would suggest to start designing the FPGA using the FPGA Vendor's schematic tool. When using schematic tools, designing the FPGA content with embedded CPU doesn't differ a lot, from the typical application design using standard components and PCB.
Difference is that you do not need to design PCB, but only design a correct schematic of your application. Inside the FPGA you simply put the CPU symbol on your schematic, do the same with needed memories, I/O buffers and other stuff, compile and ... that's all.
In the embedded CPU and FPGA internal blocks, all the busses are unidirectional with separated DATAI, DATAO and ADDRESS busses. So you simply connect CPU address bus with the address on memory, DATAO from CPU to DATAI in memory, and CPU DATAI to DATAO from memory.
Designing the I/O's, There is no problem with the ordinary Input or Output Pins, which are simply connected to inputs or outputs on CPU.
With the bidirectional pins, you need to use one of the available inside the FPGA buffers. Open drain, Tri State buffer etc.
Duane thanks for that. I meant that every IP Core we offer, has got its own specification, but when a customer tells us what he/she exact needs - we're tailoring our core to his/her needs. And re ...
I haven't tried this with AXI yet, but I assume it's similar to how PLB works: Xilinx EDK has a wizard for generating an interface to your code. You can choose either a 'register' interface to your code (in which case it generates a chip-select for each register), or 'memory'-style interface (in which case it generates a single chip-select that is active for an address range). If your code can respond to the bus in one clock cycle, then you can simply wire the rd_ack directly to the rd, and the wr_ack directly to the wr, and you must read/write data from/to the bus in one bus clock cycle. That is the simplest method.
process(bus_clk)
begin
if (rising_edge(bus_clk)) then
if (bus_cs0='1' and bus_wr='1') then
leds <= bus_data(0 to 3);
end if;
end if;
end process;
bus_rdack <= bus_rd;
bus_wrack <= bus_wr;
Hopefully, my kindle won't remove the paragraph spacing when I submit this comment. If so, I'll fix it later.
In order to implement the components of a new chip design, any IP core should be delivered with everything needed to design, test, and validate that core in the target product.
If you are interested in licensing a third-party IP core, it's a good idea to ensure that the vendor can also supply you with the debugger. The ideal situation is to obtain the debugger together with the IP core -- all from one vendor.
To save this item to your list of favorite All Programmable Planet content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
