Jump to content

kuncikehidupan

Members
  • Content Count

    23
  • Joined

  • Last visited

About kuncikehidupan

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  • Location
    Shanghai - Kuala Lumpur - Jakarta

Recent Profile Visitors

336 profile views
  1. Hello, I tried to make an array like tlm_generic_payload buffer[10] and then buffer = a, which a is another tlm_generic_payload object. However it gives me an tlm_gp.h:199 error during compilation. I would like to know whether or not several transaction (tlm_generic_payload) object can be stored in an array or C STL like queue? Thank you. Arya.
  2. kuncikehidupan

    Determining appropriate delay time

    Hi Alan, This is helpful! Thanks very much.
  3. kuncikehidupan

    Determining appropriate delay time

    Hi Alan, Thanks for your response. Yes it is absolutely device specific, DMA controllers can be fly-by too, so obviously the clock cycle requirement would be different from one to another. Back to my original question that if we are developing a model from scratch, let say a peripheral that delivers specific task (unique), and we are using SystemC - TLM to do the high level modeling for it, either in LT or AT abstraction level. How all those clock cycles information relates to the delay time need to be passed into the function call? At this point I suppose that at least the engineer/designer has already received the information about how many clock cycles that particular operation will take place in the RTL model. Is there a way to convert those clock cycles information to a value in SC_NS or SC_US during high level simulation (platform with ISS with configurations of 100MIPS and 1 SC_US default global quantum value)? Anyway when you know how many clock cycles certain operations take place, what is good about it when in LT and AT we don't model the clock at all? Should we just pass random value to the function call as the model delay? (non-sense) I am quite confused with this issue, appreciate any feedbacks. Thanks!
  4. kuncikehidupan

    SystemC TLM Custom Payload

    Hi Zubin, Yes it is possible. The TLM payload extension gives programmer the ability to develop custom payload/transaction. For b_transport method, you must provide the target with the callback function that later on you have to register it with sockets (more convenient to use). Within the same model you can register as many sockets as you want to a single callback function. You can register each of the sockets to that one callback function to provide same functionality for all of your sockets. Socket here is more like port+interface, for more accurate explanation you can refer to IEEE SystemC language reference documentation. Since you mentioned that you want to speed up software development procests, I think SystemC - TLM is your best way to achieve it. It provides you with several abstraction level that really targets the pain in your D/V flow. For software development purpose, you could try to build the model in SystemC with TLM-LT. I hope this helps. Regards, Arya.
  5. kuncikehidupan

    Determining appropriate delay time

    Thanks Alan. But my main concern is how to determine the value. I know for the b_transport we can put the delay time to the function parameter. However, how to find the "right" amount of delay time? For example I am developing a dma controller module in high-level (TLM-LT), therefore for each dma transfer happen how big is the delay time? I may put 10ns, 100ns, 1000ns, but I couldn't understand which one is the "right" one. Could you please help me to figure out how to put the "right" amount of delay time.
  6. Good day, I have a question regarding how to determine the appropriate delay value for the wait( ) function call. In the target b_transport callback, we can add delay to the simulation time by passing delay amount to the wait( ) function. In simulation that uses quantum and temporal decoupling that targets super fast instruction accurate simulation, the timing does not have to be very detail (loosely timed). With or without delay in the target callback function will not cause any functional inaccuracy and still we could produce the platform that can support firmware/software development. Still if we want to put a delay to the wait( ), how can we determine the appropriate delay value for the function parameter? Thank you. Regards, Arya.
  7. kuncikehidupan

    Introduction to SystemC TLM Verification

    Thanks Alan and everyone. Appreciate all your thoughts.
  8. kuncikehidupan

    Convenience Socket for NoC Mesh

    Thanks for your response David. I would like to answer to my original question here. I found the solution few months ago but forgot to update back here. The error has been fixed by adding debug transport function to the network model. I was working with TLM-LT open sourced ISS tool. The tool eventually utilize the debug transport function call to load application/firmware to the memory(ROM) for the cpu model to run it. Regards, Arya.
  9. kuncikehidupan

    Introduction to SystemC TLM Verification

    Hi Ruchir, Thank you for the complete detail answer, really helpful. I just realised it that SV in UVM-SV stands for SystemVerilog, so without doubt this one is obvious. If you still remember the workaround to fix the memory leakage issue, kindly post it here so me and everyone else could fix it in our local copy. Regards, Arya.
  10. kuncikehidupan

    Introduction to SystemC TLM Verification

    Hi Ruchir, I find it helpful. In my case, I got verified RTL and now developing functional model, so the adapter layer (I will choose to use UVM Connect from Mentor) is used with reusable test scenarios from the SystemVerilog testbench. Correct? One day job sounds good enough, If the above statement is correct then I can directly use the SystemVerilog testbench with the adapter to test the functional model. Yes? Since you mentioned about UVM-SC and UVM-SV in your post, may I ask you where to download these materials? Can you give a brief summary of the advantages and disadvantages of using UVM-SV vs UVM-SC vs SCV vs UVM Connect (or any other adapter layer)? Thank you. Regards, Arya.
  11. kuncikehidupan

    Introduction to SystemC TLM Verification

    Hi Ruchir, UVM stands for Universal Verification Methodology, but it is not really "universal". As pointed clearly by Mr. Martin Barnasconi in http://accellera.org/images/news/newsletter/Using-UVM-in-SystemC-DVConUS-2014.pdf I am aware of Mentor's UVM connect since long time ago, but personally I am not sure whether or not it is suitable. There are differences between block and system level verification. Have you ever tried any of those EDA adapter layer? May I ask for your advice about the big picture of it? For example if I already have the systemverilog uvm testbench, can it be used directly using the adapter layer without any modification. Hi Alan, Yes. The UVM-SC sounds promising, but it seems like it is still under development. Especially for the assertions and coverage part. In case I do not get this very clear, is this UVM-SC currently available to use? Where to download? Accellera already got SCV, so this UVM-SC is intended to replace that SCV? Thank you. Regards, Arya.
  12. kuncikehidupan

    Introduction to SystemC TLM Verification

    Hi Dinesh, But SCV does not have the functional coverage? Thank you. Arya.
  13. kuncikehidupan

    Architectural Exploration

    SystemC is super-set of C++, which gives designer ability to simulate concurrent processes that makes it suitable for defining hardware modules containing parallel processes. It is using plain C++ syntax, so SystemC is more like a library extension. SystemC platform is not always cannot be synthesized, it depends on the abstraction level (use cases) you are in. You can build a platform using SystemC (perhaps with TLM) on a particular abstraction level (choose one that target your pain in D/V the most) that can be synthesized, just like RTL you can't simply synthesize a behavioral RTL design. For the synthesize part, you can go for the HLS tool to give you the HDL code based on your SystemC model. There are the free one like Panda and xPilot, and also the paid one from Forte Design Systems, Cadence, etc. Architectural exploration is the ability for a designer to measure their architecture performances and do exploration on it, to get the best performance of it. In SystemC with TLM, generally speaking you can create your model easier and run the simulation faster compare to RTL, in this sense architecture exploration in this level is more favourable.
  14. Hi all, After developing a virtual platform using SystemC with TLM, and also several peripherals (IP) model in high-level (LT), I realised that if in RTL design there is a UVM to say that the design is "okay". How about in high-level? Is there any methodology that we could adopt? If there is none, may I ask for your suggestion on how to verify our own SystemC TLM (LT) design? The SystemC Verification subforum seems to be obsolete, so I posted it here. Really appreciate any kind of advice and solution. Thank you. Regards, Arya.
  15. Hi Accellera forum, I have an NoC Mesh that is using convenience tagged socket for its North, South, West, and East socket. Then I also have initiator socket and target socket, to connect this NoC node to the processor or memory or to any other peripherals in my SystemC-TLM platform. My question is can we implement more than one blocking transport function inside one SystemC module? Because the functionality of N,S,W,E socket are different with the target socket one. Several transaction are passed to the correct destination node, until at one point there is a transaction that has so big transaction.get_address( ) value (0xffffffe0) which leads to simulation error. It is clear that the transaction address can't be routed to any of the node because there isn't any address that large inside the platform architecture. I have test the application using processor - decoder - memory, and it works just fine. My best guess is that maybe my socket implementation is not correct 100%. Appreciate any suggestion and feedback. Thank you. Regards, Arya.
×